Branch naming convention

[Mirco Dotta]

Hi folks,

The IDE is improving day after day and we are not far from having a 2.0.0 final release.
There are still a few blockers, but overall I believe we are in good shape and 2.0.0 will
happen soon enough.

Before the final release, we would like to set some convention for naming branches.
The intent is to make it easier for new and experienced contributors to tell what each
branch is about.

First, wip_experiment branch will be merged to master and wip_experiment branch will
be deleted. This should not affect anyone work, as you will be simply request to merge
any future change with master instead of wip_experiment. If none oppose, I'll do that during
the week and send a message in the mailing list when this is done.

Then we'd like to suggest the following naming convention for branches:

If you are working on a new feature you should name your branch `feature/xxx`, where xxx
is a short meaningful name for the feature. The name should be (all) lowercase and each word
separated by a '-'. For example, `feature/indigo-compat` is a valid choice.

If you are working on a ticket, then you should name the branch `ticket/N`, where N is the ticket's
number. For example, 'ticket/1000478`.

David, for the wip_exp_backport branch I'd suggest to use a similar convention. Something like
`backport/master`, `backport/feature/xxx` and `backport/ticket/N`. What do you think?

Once agreed on the convention, we need to implement it. It'd be good if the person who created
the branch will take care of the renaming (if necessary). If one of your branch is no longer in use
(e.g., you already merged its content in wip_experiment), please go ahead and delete it. One word
of advise, if several people are working on the same branch, please do synchronize with them
before performing the rename, as this is a disruptive change.

Let me know guys if I forgot something (maybe we need more categories), and feel free to suggest
alternatives if you think they make more sense.

Cheers,
Mirco

[Mirko Stocker]

On Wednesday 07 September 2011 11:44:03 Mirco Dotta wrote:
> The IDE is improving day after day and we are not far from having a 2.0.0
> final release. There are still a few blockers, but overall I believe we are
> in good shape and 2.0.0 will happen soon enough.

Yippee

> Let me know guys if I forgot something (maybe we need more categories), and
> feel free to suggest alternatives if you think they make more sense.

I think that sounds like a good plan, so +1 from me!

Cheers,

Mirko

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[Miles Sabin]

On Wed, Sep 7, 2011 at 12:37 PM, Mirko Stocker <m...@misto.ch> wrote:
> On Wednesday 07 September 2011 11:44:03 Mirco Dotta wrote:
>> The IDE is improving day after day and we are not far from having a 2.0.0
>> final release. There are still a few blockers, but overall I believe we are
>> in good shape and 2.0.0 will happen soon enough.
>
> Yippee
>
>> Let me know guys if I forgot something (maybe we need more categories), and
>> feel free to suggest alternatives if you think they make more sense.
>
> I think that sounds like a good plan, so +1 from me!

Yup, sounds good to me as well ...

Will definitely be good to get the mainline back on master.

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[Matt Russell]

+1...it'd be good to write up the conventions on the wiki, too, which I've started here: 

  http://www.assembla.com/spaces/scala-ide/wiki/Branches

[Mirco Dotta]

Yep, I intend to do so. I just wanted to hear from you guys if you agreed on the convention :)

[emolitor]

Hurray +11

So something like Indigo improvements would just be a feature.

feature/indigo
feature/juno
feature/klaxon
etc...

- Eric

[David Bernard]

I'm fine with feature/xxx, ticket/xxx

I'm fine with rename wip_experiment and wip_exp_backport but not as master and backport (resp).

my pref  (doesn't change, see previous message (linked below) + schema ) :

* wip_2.x.y + staging_2.x.y + solid_2.x.y

* wip_1.x.y + staging_1.x.y + solid_1.x.y

(x.y is the final name, not placeholder for number, see like a mask for hosted version)

schema : http://scala-ide-dev.googlegroups.com/attach/6b0274285db1bbcf/code_version_workflow.png?view=1&part=4

  you can replace bugfix/zzzz by ticket/zzzz and wip/zzzz by feature/zzzz to match the current proposal.

Because :

* we should take care of versionning and release process

* wip_exp_backport is not only a backport (backport is minor vs other change)

* there is no master update-site, no so master branch

* I would like to avoid the bad experience of long fork like wip_experiement was (~ 6 month) and the confusion vs master.

As I'm less active than before (day job, familly,...) and TypeSafe, my POV is minor.

previous message where I explain my POV :

* http://groups.google.com/group/scala-ide-dev/msg/c237675c57c831ae

* http://groups.google.com/group/scala-ide-dev/msg/6b0274285db1bbcf (with a diagram)

previous thread of discussion about branch management :

* http://groups.google.com/group/scala-ide-dev/browse_thread/thread/f64464e34ef765c4

* http://groups.google.com/group/scala-ide-dev/browse_thread/thread/763be84c030f14b4

/davidB

PS: Sorry, I have several day of delay in processing my email's inbox.

[ijuma]

Great that this is being discussed.

On Wednesday, 7 September 2011 10:44:03 UTC+1, Mirco Dotta wrote:

If you are working on a new feature you should name your branch `feature/xxx`, where xxx
is a short meaningful name for the feature. The name should be (all) lowercase and each word
separated by a '-'. For example, `feature/indigo-compat` is a valid choice.

If you are working on a ticket, then you should name the branch `ticket/N`, where N is the ticket's
number. For example, 'ticket/1000478`.

I think this should be clarified a bit. First, shouldn't people be encouraged to file a ticket for the feature they're working on? If so, then does it make sense to have a separation between tickets and features? On the other hand, I think it would make sense to have an area for long-lives branches (or maybe they could remain in the root).

Best,

Ismael

[Mirco Dotta]

Hi David,

I'm fine with rename wip_experiment and wip_exp_backport but not as master and backport (resp).

my pref  (doesn't change, see previous message (linked below) + schema ) :

* wip_2.x.y + staging_2.x.y + solid_2.x.y

* wip_1.x.y + staging_1.x.y + solid_1.x.y

I've looked at the discussion threads you mentioned. I'm suggesting to use master because this is 

the place devs used to git expect to have the latest basecode for the IDE. If I'm new to the project, the 

first thing I'm going to do is to have a look at the sources, and master is definitely the place where I'd 

look. IMO, if I've to read a document to know what branch I need to look at for getting the latest sources 

(as it is the case nowadays), you lost me already.

Going back to your schema, I don't think we can afford having three different development branches, 

we are missing the resources for that and we should really strive for keeping things simple and manageable.

I'll try here to describe the workflow I have in my mind (I plan to have this a little more formalized in a wiki 

page at some point in the future, and this is also something I have to discuss with you guys).

Until the RC1 for 2.0.0, all changes go directly into master (once I merged wip_experiment back into master). 

The moment we get out with a release candidate, we need to branch master. Let's say we call this new branch 

`maintenance/scala-ide-2.0.x`. At this point master will became the de-facto mainline for 2.1.0. If 2.0.0.RC1 will 

have no problems, it will automatically became the 2.0.0.final release, and the dev branch 

`maintenance/scala-ide-2.0.x` will now be used (mostly) for backporting fixes/features from master. At some point 

we will push a new maintenance RC for 2.0.1, which will eventually get into a final release. 

`maintenance/scala-ide-2.0.x` will then hold sources for the following 2.0.2 maintenance release.

I hope I've done a decent work in explaining the workflow, please ask if something is unclear or does not make sense.

The directory structure of the project will then look something like the following:

  | - master

  | - maintenance

            | - scala-ide-2.0.x (the 'x' can be dropped, this is simply a proposal)

  | - feature

            | - indigo-comp

            | - scaladoc-hover

  | - ticket

            | - 1000508

  | - backport (maybe we can pick a better name for it)

            | - master

            | - maintenance

                      | - scala-ide-1.1.x

            | - feature

                      | -  semantic-higlight

            | - ticket

                      | - 1000496

           

Naturally, every time we do a beta/RC/milestone/final release, a tag is created as usual.

* we should take care of versionning and release process

I don't see any problem with the release process and/or versioning by adopting what I described above. These are 

somewhat orthogonal to the project's directory structure. Would you have any objection?

* wip_exp_backport is not only a backport (backport is minor vs other change)

Ok, maybe I'm using a poor name for describing your work, sorry about that. Instead of backport you can choose any 

other meaningful name (though, I think it'd be good to keep it as short as possible).

* there is no master update-site, no so master branch

IMO, this is a detail and it shouldn't affect our project's directory structure. I believe that in the future the update-site addresses will 

be changed (a redirect will be kept), but this is a topic for another discussion thread ;)

* I would like to avoid the bad experience of long fork like wip_experiement was (~ 6 month) and the confusion vs master.

Exactly my point. With the current state, it is confusing that master does not contain the latest, up-to-date, stream of code for the IDE.

That's why we should reorganize things before the final release, as we would like to get more contributors interested in the project. 

It is really about lowering the barrier and make the whole repository consistent.

my POV is minor.

Disagreed :) Discussion is important to avoid making the wrong moves and waste time. I'm happy you questioned my proposal, as 

it pushed me thinking a little more about it and see how things will develop in the future. 

Please, everyone, feel free to comment on anything I said, we definitely need to agree before we can take any action.

Cheers,

  Mirco

[Mirco Dotta]

Hi Ismael,

> I think this should be clarified a bit. First, shouldn't people be encouraged to file a ticket for the feature they're working on? If so, then does it make sense to have a separation between tickets and features? On the other hand, I think it would make sense to have an area for long-lives branches (or maybe they could remain in the root).

I agree, feature and ticket are somewhat overlapping. Ideally, this is how I intended them to be used:

`feature` should be used for involved tasks, that will likely take days/weeks/months before getting merged
into the mainline. Maybe, if a ticket is open for the feature you are working on, then we could say that the
ticket number should be postfixed, e.g., feature/scaladoc-hover-1000210. And yes, I would like to push on
opening enhancements tickets before creating a branch, when that makes sense.

On the other hand, I expect branches created under `ticket` to have a (very) short live period. Most of the time,
fixing a bug boils down to changing a few lines in one or two files. Hence, often you don't even create a
(remote) branch for a ticket. However, there are times when you do want to have a branch. For example, to get
some feedback. In which case you can push the branch under `ticket`.

I know the definition is far from being formal, but I think common sense (with a short wiki page ;) should be enough
to decide if a branch should go under `feature` or `ticket`.

Does that make sense to you?

-- Mirco

[Mirco Dotta]

> Hurray +11

:)

> So something like Indigo improvements would just be a feature.
> feature/indigo
> feature/juno
> feature/klaxon

I have been discussing this with Iulian and we think it would be better have them under `platform`:

`platform/indigo`
`platform/juno`
`platform/klaxon`

Though, one point that is still unclear to me is how we are going to proceed with supporting different
Eclipse platforms. At the moment, the officially supported platform is Helios, and we work on best-effort
to also support Indigo. But as you have noticed, Indigo is less stable and we miss the resources for offering
the same quality on both.

Iulian has always pushed to have one single codebase that can work against both Helios and Indigo (again,
because of resources constraints). Though, the more platforms there will be, the lower are the chances that we
can keep one single codebase for all of them. Hence, in the future we will have to decide to either drop support
for some platform, or else to have different branches for each platform and then make sure to push them forward
together.

Maybe it would be good to start a discussion on a different thread about this topic, I think it'd be good to clear this up.

-- Mirco

[David Bernard]

On Thu, Sep 8, 2011 at 11:35, Mirco Dotta <mirco...@gmail.com> wrote:

Hi David,

I'm fine with rename wip_experiment and wip_exp_backport but not as master and backport (resp).

my pref  (doesn't change, see previous message (linked below) + schema ) :

* wip_2.x.y + staging_2.x.y + solid_2.x.y

* wip_1.x.y + staging_1.x.y + solid_1.x.y

I've looked at the discussion threads you mentioned. I'm suggesting to use master because this is 

the place devs used to git expect to have the latest basecode for the IDE. If I'm new to the project, the 

first thing I'm going to do is to have a look at the sources, and master is definitely the place where I'd 

look. IMO, if I've to read a document to know what branch I need to look at for getting the latest sources 

(as it is the case nowadays), you lost me already.

About "master", there are several schools :

* master == the last release (cf git flow,...)

* master == the current dev (integrated)

* there is no master branch and HEAD point to what git dev wants as default starting branch for "new cloner".

(you don't need to merge into master, master is just a name/alias, so you can rename wip_experiment to master)

you look at the lastest sources of what ? the dev, the version you use.

IMO If there is no master, then user will select to the version/branch he used/want to work on.

 

Going back to your schema, I don't think we can afford having three different development branches, 

we are missing the resources for that and we should really strive for keeping things simple and manageable.

It's no 3 development branches. it 3 channels (branch + update-sites) :

* wip = developement

* staging = stable but not "release" (in your words the place for milestone, beta, RC, maintenance)

* solid = stable "release"

when you push to staging_ then the update site is updated and user that want "early access" can used (less work than the current process of "releasing")

I use this process for backport, when I want to publish a stable version from wip_exp_backport I push to the milestone branch.

I'll try to challenge, complete my comments, later tonight (when I'll back to home)

Cheers,

/davidB

[Matthew Farwell]

2011/9/8 Mirco Dotta <mirco...@gmail.com>

Hi David,

I'm fine with rename wip_experiment and wip_exp_backport but not as master and backport (resp).

my pref  (doesn't change, see previous message (linked below) + schema ) :

* wip_2.x.y + staging_2.x.y + solid_2.x.y

* wip_1.x.y + staging_1.x.y + solid_1.x.y

I've looked at the discussion threads you mentioned. I'm suggesting to use master because this is 

the place devs used to git expect to have the latest basecode for the IDE. If I'm new to the project, the 

first thing I'm going to do is to have a look at the sources, and master is definitely the place where I'd 

look. IMO, if I've to read a document to know what branch I need to look at for getting the latest sources 

(as it is the case nowadays), you lost me already.

+1 for master. For me, this is not only about organization, but about communication. master is standard git-speak for 'main development branch, probably quite unstable, may not even compile, expect some weirdness here'.

If we look at this with the eye of an occasional contributor (me for example), I can see that there are really only two branches that I will care about:

1) master (which I will use as the basis of my work)

2) The branch I'm currently working on. Which will either be feature/010101-scaladoc-goodies or ticket/010101-eclipse-dies-horrible-death, and created by me.

For virtually anything else:

The maintenance branches I probably won't touch, because that involves heavy duty work and testing. I simply don't have the knowledge and experience with the code to put a fix into one of the maintenance branches; I would have to ask on here before I merged a fix into one of the maintenance branches.

The same applies to the backports. This is something I wouldn't touch lightly. I'd have to consult heavily before touching this stuff, if I ever thought about it at all.

My point is that for a casual/new contributor, all I need to know to do some work is that I should create a branch for my work called feature/xxx-xxx or ticket/xxx-xxx. Then I either send the patch to you lot, or ask for a code review. Then I merge into master. I don't need to know all of the details about management of maintenance branches.

Umm, as a recommendation, the wiki page should be split into two sections: For casual contributors and a more complete version for those who wish to know.

* I would like to avoid the bad experience of long fork like wip_experiement was (~ 6 month) and the confusion vs master.

Exactly my point. With the current state, it is confusing that master does not contain the latest, up-to-date, stream of code for the IDE.

That's why we should reorganize things before the final release, as we would like to get more contributors interested in the project. 

It is really about lowering the barrier and make the whole repository consistent.

my POV is minor.

Disagreed :) Discussion is important to avoid making the wrong moves and waste time. I'm happy you questioned my proposal, as 

it pushed me thinking a little more about it and see how things will develop in the future. 

My POV is minor. This really *is* true for me. :-)

Matthew.

 

[Miles Sabin]

On Thu, Sep 8, 2011 at 12:20 PM, Matthew Farwell <mat...@farwell.co.uk> wrote:
> My POV is minor. This really *is* true for me. :-)

On the contrary ... the goal is get the barrier to entry for casual
contributors as low as possible. And for that the simpler the better.

So +10 to Mirco's proposal from me.

[Matthew Farwell]

2011/9/8 Mirco Dotta <mirco...@gmail.com>

+1 for being pragmatic about this. Most of the time most work will only be done locally, so there will be few ticket/xxx branches, and a few more feature/xxx branches.

The main difference between the two, apart from the longevity of the work, is communication or documentation. You would want to create a new branch on the server if you're asking for a code review or similar. And if you're asking for a code review, it helps to have the ticket or feature in the branch name, because it gives an indication of what the code is for.

Matthew.

[ijuma]

Hi Mirco,

On Thursday, 8 September 2011 11:20:44 UTC+1, Mirco Dotta wrote:

I agree, feature and ticket are somewhat overlapping. Ideally, this is how I intended them to be used:

Thanks for the explanation. 

`feature` should be used for involved tasks, that will likely take days/weeks/months before getting merged
into the mainline. Maybe, if a ticket is open for the feature you are working on, then we could say that the
ticket number should be postfixed, e.g., feature/scaladoc-hover-1000210. And yes, I would like to push on
opening enhancements tickets before creating a branch, when that makes sense.

On the other hand, I expect branches created under `ticket` to have a (very) short live period. Most of the time,
fixing a bug boils down to changing a few lines in one or two files. Hence, often you don't even create a
(remote) branch for a ticket. However, there are times when you do want to have a branch. For example, to get
some feedback. In which case you can push the branch under `ticket`.

I know the definition is far from being formal, but I think common sense (with a short wiki page ;) should be enough
to decide if a branch should go under `feature` or `ticket`.

That's clearer. I would suggest a couple of changes. Rename ticket to 'issue' or 'bug' as I don't think 'ticket' is descriptive (and as discussed features can have tickets). And include text in both. Now, I am undecided between prefix or postfix notation (both have advantages and disadvantages):

feature/010101-scaladoc-goodies or issue/010101-eclipse-dies-horrible-death vs

feature/scaladoc-goodies-010101 or issue/eclipse-dies-horrible-death-010101

The text makes it easier to scan entries than just having a ticket number, I think that is not controversial. Prefix ticket numbers make tab-completion work better if you know the ticket number while postfix makes it for more regular names when there is no ticket number.

What do you think?

Best,

Ismael

[emolitor]

On Thursday, September 8, 2011 12:45:03 PM UTC+1, ijuma wrote:That's clearer. I would suggest a couple of changes. Rename ticket to 'issue' or 'bug' as I don't think 'ticket' is descriptive (and as discussed features can have tickets). And include text in both. Now, I am undecided between prefix or postfix notation (both have advantages and disadvantages):

feature/010101-scaladoc-goodies or issue/010101-eclipse-dies-horrible-death vs

feature/scaladoc-goodies-010101 or issue/eclipse-dies-horrible-death-010101

The text makes it easier to scan entries than just having a ticket number, I think that is not controversial. Prefix ticket numbers make tab-completion work better if you know the ticket number while postfix makes it for more regular names when there is no ticket number.

I prefer the ticket/description approach as it is far more transparent than just ticket numbers. I do think that features should be separated from issues and think the naming convention of issue over ticket is best. I also agree that all features should have tickets. In other words I agree with pretty much this whole thread.

- Eric

[Mirco Dotta]

About "master", there are several schools :

* master == the last release (cf git flow,...)

* master == the current dev (integrated)

* there is no master branch and HEAD point to what git dev wants as default starting branch for "new cloner".

David, I understand your point, but since we are using git I think it makes it easier for everyone to stick with its 

standard. It seems all other committers would find it more convenient, and I do think it will remove one level of

complexity for new comers.

Since you are responsible for the backport, if adopting the the same structure would make you less productive, 

I think it is ok if you implement a different one. If you decide to go down this path, I think it would be good to produce a 

wiki page that explains the organization and workflow. 

(you don't need to merge into master, master is just a name/alias, so you can rename wip_experiment to master)

The plan is to delete wip_experiment branch. It's really useless to let it around if it's simply an alias for master (again,

let's try to make it simpler if we can).

you look at the lastest sources of what ? the dev, the version you use.

IMO If there is no master, then user will select to the version/branch he used/want to work on.

I disagree here. Committers won't be "allowed" to just commit on any branch. For example, `maintenance/scala-ide.2.0.x` will 

only see few selected upgrades cherrypicked from master. I think Matthew's answer on this topic describes exactly what I have in mind

(I'm quoting him here):

"The maintenance branches I probably won't touch, because that involves heavy duty work and testing. I simply don't have the knowledge 

and experience with the code to put a fix into one of the maintenance branches; I would have to ask on here before I merged a fix into one 

of the maintenance branches."

That implies that at any point in time there is only one true dev branch, i.e., master.

It's no 3 development branches. it 3 channels (branch + update-sites) :

* wip = developement

I guess what we want to name master

* staging = stable but not "release" (in your words the place for milestone, beta, RC, maintenance)

No need for this. Or at least, there is no need to have an ongoing increasing number of branch over time.

Every time we do a beta/RC/milestone/final there is a tag and we keep only a single 

`maintenance/scala-ide-2.0.x` branch for periodic maintenance releases. That's it, I don't see how it could be any

simpler.

* solid = stable "release"

when you push to staging_ then the update site is updated and user that want "early access" can used (less work than the current process of "releasing")

This are what nighties are for, aren't it?

-- Mirco

[Mirco Dotta]

On Sep 8, 2011, at 1:45 PM, ijuma wrote:

I would suggest a couple of changes. Rename ticket to 'issue' or 'bug' as I don't think 'ticket' is descriptive (and as discussed features can have tickets).

I'm ok with naming it 'issue'. So if none oppose, agreed :)

And include text in both.

Agreed on that as well, let's keep conventions to a bare minimum.

Now, I am undecided between prefix or postfix notation (both have advantages and disadvantages):

feature/010101-scaladoc-goodies or issue/010101-eclipse-dies-horrible-death vs

feature/scaladoc-goodies-010101 or issue/eclipse-dies-horrible-death-010101

The text makes it easier to scan entries than just having a ticket number, I think that is not controversial. Prefix ticket numbers make tab-completion work better if you know the ticket number while postfix makes it for more regular names when there is no ticket number.

What do you think?

Yep, tab-completion is actually a big plus on favor of prefixing the ticket number. Considering both 'feature' and 'issue' will ideally 

be matched to a ticket, it may be better to be pragmatic and prefixing the ticket number so that we can type less :)

-- Mirco

[ijuma]

Great!

Ismael

[iulian dragos]

It's great to see this re-haul, thanks Mirco for stepping up and driving this!

I have but a small remark. I'd prefer having the ticket number at the
end, precisely for better tab completion. For me it's harder to
remember a ticket number, and anyway the first 4 digits of all tickets
are the same.. it's most likely that only one digit will differ
between branches.

cheers,
iulian

> -- Mirco

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[David Bernard]

when you push to staging_ then the update site is updated and user that want "early access" can used (less work than the current process of "releasing")

This are what nighties are for, aren't it?

No.
By reading your comments and replies on previously thread. I unnderstand I failed to explain the workflow.

I'll try to explain it in other place (blog). Until then :

+1 for 'master' as host of current dev and source for nightlies

  * I proposed to rename wip_experiment to master and not to "git merge" : less work and less error prone

    see http://stackoverflow.com/questions/21848/switch-branch-names-in-git

+1 for 'issue/NNNNN_description'

  * NNNN will always match the number of the ticket, but description will rarely match the title of the ticket so harder for completion

  * about completion, I suggest you to use zsh + oh-my-zsh, completion (of filename, branch) is done on any part of the name (not only on the begin)

About dev that are not associated to a ticket, eg : feature/foo a particite can be to prefix the feature name by the start date, it help to see old feature without browse history/graph... and how long it take to develop the feature when ready to merge into master : feature/YYYYMMDD_foo

About 'backport', why not using maintenance/scala-ide-1.x.y ('x.y' are not placeholders) ?

Thanks for taking the time to read my long mail and previous discussion.

Cheers,

/davidB

[Mirco Dotta]

  * I proposed to rename wip_experiment to master and not to "git merge" : less work and less error prone

    see http://stackoverflow.com/questions/21848/switch-branch-names-in-git

Absolutely agreed. Thx for the link!

+1 for 'issue/NNNNN_description'

  * NNNN will always match the number of the ticket, but description will rarely match the title of the ticket so harder for completion

I don't actually have a strong opinion on that. I think either solution would work (prefixing or suffixing the ticket's number) and they 

are pretty much equivalent. I'd leave you guys decide.

  * about completion, I suggest you to use zsh + oh-my-zsh, completion (of filename, branch) is done on any part of the name (not only on the begin)

About dev that are not associated to a ticket, eg : feature/foo a particite can be to prefix the feature name by the start date, it help to see old feature without browse history/graph... and how long it take to develop the feature when ready to merge into master : feature/YYYYMMDD_foo

I'm against adding the branch creation date in the name. I don't think it adds much value and it has the clear drawback of 

(1) extending the name and (2) making the convention a little harder to remember.

About 'backport', why not using maintenance/scala-ide-1.x.y ('x.y' are not placeholders) ?

Yes, that's even better! 

-- Mirco

[Mirco Dotta]

Alright, yesterday I spent some time editing the wiki page that
formalizes what we discussed.

http://scala-ide-portfolio.assembla.com/spaces/scala-ide/wiki/Branches

I made a few changes in the project's structure and workflow to
include all the good suggestions you had.
Let me know if you have any objection.

My plan is to make the proposal final by next Friday 23th of
September. After that, I expect that branches
will be renamed/deleted by their own creators in a matter of days.

@Eric: Iulian mentioned you may be integrating your forks back in the
project. That's why I thought to have a
`platform` folder containing your work. Does that sound ok to you?

-- Mirco

On Sep 9, 10:28 am, Mirco Dotta <mirco.do...@gmail.com> wrote:
> >   * I proposed to rename wip_experiment to master and not to "git merge" : less work and less error prone

> >     seehttp://stackoverflow.com/questions/21848/switch-branch-names-in-git

[emolitor]

Yes, sounds reasonable.

[Mirco Dotta]

My plan is to make the proposal final by next Friday 23th of
September. After that, I expect that branches
will be renamed/deleted by their own creators in a matter of days.

Since none objected, I think we can move on and start acting. 

Tomorrow (Monday) morning, I will rename wip_experiment branch to be master. 

When done I'll send a message in the mailing list.

In parallel, I would ask all branches' owner to rename their branches as described in

http://scala-ide-portfolio.assembla.com/spaces/scala-ide/wiki/Branches

Further, please delete (your) old branches that have been already merged back in the 

mainline. 

It would be good if by next Monday 3rd of October we have a well organized repository.

Cheers,

  Mirco

[Mirco Dotta]

Tomorrow (Monday) morning, I will rename wip_experiment branch to be master. 

When done I'll send a message in the mailing list.

I was willing to do that this morning but I got stuck very quickly :-/

So, before getting the project into a messy state, I decided to ask help to the assembla folks

http://forum.assembla.com/forums/3-Bug-reports/topics/3551-Safe-overwrite-of-master

Unfortunately, no answer so far. 

If any of you knows how to correctly do the process I describe in the above link, please let me 

know. I'll move forward with it the moment I have the missing information. (and I'll make sure 

to let you all know when I start the branch renaming process).

-- Mirco

---------------

Mirco Dotta

Typesafe - Enterprise-Grade Scala from the Experts 

PSE-D, 1015 Lausanne, Switzerland

Work: +41 (0)21 691 49 65

Twitter: @mircodotta

[Miles Sabin]

On Mon, Sep 26, 2011 at 1:57 PM, Mirco Dotta <mirco...@typesafe.com> wrote:
> I was willing to do that this morning but I got stuck very quickly :-/
> So, before getting the project into a messy state, I decided to ask help to
> the assembla folks
> http://forum.assembla.com/forums/3-Bug-reports/topics/3551-Safe-overwrite-of-master
> Unfortunately, no answer so far.
> If any of you knows how to correctly do the process I describe in the above
> link, please let me know. I'll move forward with it the moment I have the
> missing information. (and I'll make sure to let you all know when I start
> the branch renaming process).

Does this Stackoverflow question (and answer(s)) help?

http://stackoverflow.com/questions/1526794/git-rename-remote-branch

[Matt Russell]

On Monday, September 26, 2011 1:57:36 PM UTC+1, Mirco Dotta wrote:

If any of you knows how to correctly do the process I describe in the above link, please let me 

know. I'll move forward with it the moment I have the missing information. (and I'll make sure 

to let you all know when I start the branch renaming process).

As an alternative to force push or deleting master, could you instead merge wip-experiment into master?

-- Matt

[Mirco Dotta]

Matt, Miles, 

Thanks a lot for the suggestions!

I managed to merge wip_experiment back into master. It looks good to me, let me know 

if you see any issue.

I also created a `release/scala-ide-2.0.x` branch (copy of current master), which will be 

used for fixing tickets for the 2.0 release and for future maintenance released for the 2.0 

plugin. This means that master can soon be used for the development of the next 2.1 

plugin. We still need to update the nighties so that they point to the right branch.

Now, it's time to clean up the mess of branches that we have. Hopefully, by the beginning 

of next week we'll have a much cleaner repository.

-- Mirco

[iulian dragos]

On Mon, Sep 26, 2011 at 11:02 PM, Mirco Dotta <mirco...@typesafe.com> wrote:

Matt, Miles, 

Thanks a lot for the suggestions!

I managed to merge wip_experiment back into master. It looks good to me, let me know 

if you see any issue.

I also created a `release/scala-ide-2.0.x` branch (copy of current master), which will be 

used for fixing tickets for the 2.0 release and for future maintenance released for the 2.0 

plugin. This means that master can soon be used for the development of the next 2.1 

plugin. We still need to update the nighties so that they point to the right branch.

Now, it's time to clean up the mess of branches that we have. Hopefully, by the beginning 

of next week we'll have a much cleaner repository.

Thanks a lot Mirco! That's awesome.

I'm updating the Jenkins configuration right now.

iulian

 

-- Mirco

On Sep 26, 2011, at 5:32 PM, Matt Russell wrote:

On Monday, September 26, 2011 1:57:36 PM UTC+1, Mirco Dotta wrote:

If any of you knows how to correctly do the process I describe in the above link, please let me 

know. I'll move forward with it the moment I have the missing information. (and I'll make sure 

to let you all know when I start the branch renaming process).

As an alternative to force push or deleting master, could you instead merge wip-experiment into master?

-- Matt

[Mirko Stocker]

Hi,

On Tuesday, September 27, 2011, iulian dragos wrote:

This means that master can soon be used for the development of the next 2.1 

plugin. We still need to update the nighties so that they point to the right branch.

...

I'm updating the Jenkins configuration right now. 

 Does this mean that master is now open for 2.1 development? 

Cheers,

Mirko

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[iulian dragos]

On Wed, Sep 28, 2011 at 7:44 AM, Mirko Stocker <m...@misto.ch> wrote:

Hi,

On Tuesday, September 27, 2011, iulian dragos wrote:

This means that master can soon be used for the development of the next 2.1 

plugin. We still need to update the nighties so that they point to the right branch.

...

I'm updating the Jenkins configuration right now. 

 Does this mean that master is now open for 2.1 development? 

Give us a few more days to stabilize everything. I'll write an email once we're ready with everything :)

iulian

 

Cheers,

Mirko

--

Mirko Stocker | m...@misto.ch

Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[Mirko Stocker]

On Wed, Sep 28, 2011 at 08:15, iulian dragos <jagu...@gmail.com> wrote:
> Give us a few more days to stabilize everything. I'll write an email once
> we're ready with everything :)

Ok :-) Thanks!

[iulian dragos]

Hi all,

We reached a point where, I believe, we have a nice project setup. We
have a 2.0.x branch for stable builds (the upcoming 2.0 release), and
master for early adopters (future 2.1 release).

We have two features that wait for inclusion, and I'd like to continue
to have a 'review process' in place for anything that goes into master
as well, making sure that everything that touches the presentation
compiler is touching it the right way ;-)

I'll jump on 'Implicit highlights', since I already looked at it, and
I hope Mirco will have a look at semantic highlighting. Once the
review is done (and required changes are implemented), you can go
ahead and merge to master.

cheers, and thanks for bearing with us for all this time!
iulian

--

[Matt Russell]

On 4 October 2011 13:03, iulian dragos <jagu...@gmail.com> wrote:

> We have two features that wait for inclusion, and I'd like to continue
> to have a 'review process' in place for anything that goes into master
> as well, making sure that everything that touches the presentation
> compiler is touching it the right way ;-)
>
> I'll jump on 'Implicit highlights', since I already looked at it, and
> I hope Mirco will have a look at semantic highlighting.

Cool, although the semantic highlighting branch is not ready to merge
to master yet -- in particular, it'll need to plug in to the work
Mirko has done on the implicit highlighting branch.

-- Matt