PDA

View Full Version : 7.0/7.1 branch plan



andyg
2007-11-12, 09:04
It's about time to branch for the 7.0 release, which is expected in
the next several weeks. This time, we're thinking that it needs to be
a done a bit differently than in the past. Here is the plan:

Copy (branch) current trunk to a new directory, 7.1/trunk.
Current trunk will stay where it is, named 'trunk', and will become
the 7.0 trunk.
Bug fixes must be made to the 7.0 trunk and will be pulled into 7.1/
trunk automatically using svk.
Feature changes not destined for 7.0 must be made to 7.1/trunk.

Going forward, each minor release such as 7.1 will have its own set of
trunk, tags, and branches directories. When the time comes for 7.2,
we will copy 7.1/trunk to 7.2/trunk, and so on. This way we can
continue to make bug fixes in older releases and have them
automatically pulled down into the newer code using svk. There should
be little to no manual merging or dual-checkins needed.

If you have any comments or see a problem with this structure, please
let me know.

-Andy

dean
2007-11-12, 09:29
Andy: can you elaborate on the svn paths to the various branches?
Some examples will help.

-dean

On Nov 12, 2007, at 8:04 AM, Andy Grundman wrote:

> It's about time to branch for the 7.0 release, which is expected in
> the next several weeks. This time, we're thinking that it needs to be
> a done a bit differently than in the past. Here is the plan:
>
> Copy (branch) current trunk to a new directory, 7.1/trunk.
> Current trunk will stay where it is, named 'trunk', and will become
> the 7.0 trunk.
> Bug fixes must be made to the 7.0 trunk and will be pulled into 7.1/
> trunk automatically using svk.
> Feature changes not destined for 7.0 must be made to 7.1/trunk.
>
> Going forward, each minor release such as 7.1 will have its own set of
> trunk, tags, and branches directories. When the time comes for 7.2,
> we will copy 7.1/trunk to 7.2/trunk, and so on. This way we can
> continue to make bug fixes in older releases and have them
> automatically pulled down into the newer code using svk. There should
> be little to no manual merging or dual-checkins needed.
>
> If you have any comments or see a problem with this structure, please
> let me know.
>
> -Andy
>
>
>

andyg
2007-11-12, 09:40
On Nov 12, 2007, at 11:29 AM, dean blackketter wrote:

> Andy: can you elaborate on the svn paths to the various branches?
> Some examples will help.

Sure, this is how it would look:

7.0 trunk -> http://svn.slimdevices.com/repos/slim/trunk
7.1 trunk -> http://svn.slimdevices.com/repos/slim/7.1/trunk

Mark Miksis
2007-11-12, 10:07
Can you elaborate on what this will look like after 7.0.0 is tagged and released? Will minor bugfix changes be made to 7.0/branch (destined for a 7.0.1 release)? Will these changes be automatically merged into 7.0/trunk which, in turn, will automatically be merged into 7.1 trunk? Will 7.0 and 7.1 both have a branch? Or will 7.0 only have a branch (and not a trunk) after the release?

erland
2007-11-12, 10:10
It's about time to branch for the 7.0 release, which is expected in
the next several weeks. This time, we're thinking that it needs to be
a done a bit differently than in the past. Here is the plan:

If you have any comments or see a problem with this structure, please
let me know.

-Andy
It just feels a bit non standard.

I suppose need to turn off the automatic svk merge when we get to 8.0 ? I don't think you want all changes in the latest 7.x to automatically propagate to the 8.0 release.

For minor releases like 7.0 -> 7.1 and 7.1 -> 7.2 the automatic merge is probably fine.

Do you really need both "trunk", "branches" and "tags" for all versions ?
Won't you typically just get a single tag (for the official release) and no branches under each 7.x tree ?
Or do you plan to use tags and branches more than you have done so far ?

andyg
2007-11-12, 10:11
Can you elaborate on what this will look like after 7.0.0 is tagged and released? Will minor bugfix changes be made to 7.0/branch (destined for a 7.0.1 release)? Will these changes be automatically merged into 7.0/trunk which, in turn, will automatically be merged into 7.1 trunk? Will 7.0 and 7.1 both have a branch? Or will 7.0 only have a branch (and not a trunk) after the release?

7.0 would be tagged to tags/RELEASE_7_0 or something. Bugfixes would happen in the 7.0 trunk, there is no need for a branch here. Since 7.0 trunk is only for bugfixes, a release 7.0.1 would be released right from 7.0 trunk (and tagged of course).

Ideally branches should only be used for features someone is working on.

andyg
2007-11-12, 10:34
On Nov 12, 2007, at 12:10 PM, erland wrote:

> It just feels a bit non standard.

Heh if by 'standard' you mean 'the way we always did it', then yes.
Unfortunately there is no real standard for this stuff, I think every
project has these kinds of issues, unless they use the so-called holy
grail of version control tools, git. ;)

> I suppose need to turn off the automatic svk merge when we get to
> 8.0 ?
> I don't think you want all changes in the latest 7.x to automatically
> propagate to the 8.0 release.

Why not? I think what would happen for 8.0 is it would start off as
7.x and then at some point we'd realize it needs to become 8.0 and
rename it.

> For minor releases like 7.0 -> 7.1 and 7.1 -> 7.2 the automatic merge
> is probably fine.
>
> Do you really need both "trunk", "branches" and "tags" for all
> versions
> ?
> Won't you typically just get a single tag (for the official release)
> and no branches under each 7.x tree ?
> Or do you plan to use tags and branches more than you have done so far
> ?

Well we'd tag 7.0.1, 7.0.2, etc, as needed for bugfix releases.
Branches are for features someone is working on for that release.

We're still hashing this out internally too, nothing is decided yet.
I just wanted to see what the community had to say.

erland
2007-11-12, 10:46
ls, git. ;)

> I suppose need to turn off the automatic svk merge when we get to
> 8.0 ?
> I don't think you want all changes in the latest 7.x to automatically
> propagate to the 8.0 release.

Why not? I think what would happen for 8.0 is it would start off as
7.x and then at some point we'd realize it needs to become 8.0 and
rename it.

I was just thinking that it might be pretty large changes between 7.x and 8.0.
If you look at 6.5.4, you probably didn't want every change in there to be merged into 7.0 trunk automatically.
I many cases it would probably give the correct result, but I'm sure there are some cases where you don't want the changes to be propagated. Of course, you can always reverse the change in 8.0 after the automatic merge has happened.

Mark Miksis
2007-11-12, 10:53
So you're really just redefining what a branch and trunk mean?

- trunk(7.0) is what we used to think of as branch/7.0
- 7.1/trunk is what we used to think of as trunk
- releases are always tagged from the second-to-last trunk (what used to be the branch)
- branches are now only for working on new features that will eventually go into trunk if/when ready

andyg
2007-11-12, 10:56
So you're really just redefining what a branch and trunk mean?

- trunk(7.0) is what we used to think of as branch/7.0
- 7.1/trunk is what we used to think of as trunk
- releases are always tagged from the second-to-last trunk (what used to be the branch)
- branches are now only for working on new features that will eventually go into trunk if/when ready

Yeah, exactly. I think it makes more sense logically to have 7.1/trunk be a descendent of 7.0 trunk 'pulling' bugfixes rather than have branches/7.0 be a descendent of 7.1 and have it 'push' bugfixes back up to 7.1.

andyg
2007-11-12, 13:24
So, my proposal was a bit premature. After some internal discussion we have decided to stick with the old method and create a branches/7.0. We'll rethink the branch process post-7.0.

It will be important that all 7.0 bug fixes be checked into branches/7.0 and *NOT* into trunk. They will get pushed into trunk automatically.

Monk
2007-11-13, 07:45
A system that has worked pretty nicely for one of our products and is some sort of "standard" (following Linux Kernel dev) was:
- Using odd numbered major versions in development, i.e. what would be the current 7.0 branch
- When the dev branch was mature enough, it was released with an even major version number like 8.0
- Bugfixes and minor improvements to the released branch are handled with minor versions number
- The new dev branch gets the next odd major version, in this example 9.x

Personally I like the logic behind this numbering scheme.

Regards,

Monk