That's my understanding as well. The main point being that "old version" branches don't stick around long enough to get stale. After all, it was created because there was a a bugfix somebody felt was worth patching... it should be released at some point. In other words, create the branch for a *purpose* (in this case, to fix and release some bug fixes) or don't create it at all.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jun 4, 2013 at 10:46 PM, Sean Busbey <bus...@cloudera.com> wrote: > On Tue, Jun 4, 2013 at 10:26 PM, Benson Margulies > <bimargul...@gmail.com>wrote: > >> > 1.4.4 has been released. The first person finds some changes that should >> be >> > placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be >> > created from the 1.4.4 tag. >> >> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named >> 1.4.x? On other projects, there's an assumption of one branch per >> maintained minor version, with point releases as tags along they way. >> How is your more complex? scheme advantageous? >> > > I believe in this set up, in the absence of 1.4 non-compatible changes in > flight there would not be a 1.5 related branch unti 1.4.5-SNAPSHOT had been > tagged and removed. > > Thus, when a someone comes in provide a patch for some new bug, there are > not multiple release branches. I don't see, for example: > > * 1.4.x > * 1.5.x > * master (1.6.x) > > This means that I don't have the opportunity to go "Oh, which of these do I > put this on?" Instead I have to think: > > 1) What isn't end of life? (1.4+) > 2) Does this break compatibility for that version? > 2a) no? branch from last 1.4 tag > 2b) check next most recent release and loop 2 > > Also implied is that the normal workflow means that tagging e.g 1.4.5 would > be followed by making a 1.5.1-SNAPSHOT to roll those same fixes up to the > list of supported versions. > > In practice, if there are changes in flight non-compatible across multiple > supported versions we'll end up with multiple -SNAPSHOT versions at once > and it will look much like maintaining the 1.y.x branches. However, it will > be clear that we're in such a state and it will also be clear when things > collapse back. > > -- > Sean
