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
