That's the old issue, I guess. And mainly it hang on a couple of bearings: - the amount of work that goes into a particular release, including testing, etc. - maintenance of the multiple release trains
I appreciate the reasons to have more frequent dot-releases and updating current base version of the stack with newer versions of some components. I don't think anyone in the community will object such an effort. But as usual it is the question of the people priorities and the time they can volunteer to the project. We had an experience of supporting 0.3.x line for Hadoop 1.x which has never panned out to anything material. Perhaps because of the generic lack of interest in Hadoop 1.x support as well as complexity of supporting of two very different release trains. Let me put it this way: I am pretty sure everyone will be very enthusiastic to support an effort like this if there's someone to champion the next dot-release. Cos On Sat, Feb 07, 2015 at 11:33PM, [email protected] wrote: > In looking over the 0.9 BOM jira and tracking the list more recently about > updates and release work ongoing wanted to get sense of what the group > thoughts are on versioning and what it means in bigtop to have a patch and > minor release. > > Looks like group has 0.9 in its crosshairs to push to completion then > turning towards 1.0. If looking at from semver style, has group discussed > in past doing patch versioning to do minor revs on components? > > Example would be the 0.9 jira started in Oct, since then two versions of > spark have rolled through with already an update patch ready for spark 1.1 > for 0.9. Could bigtop look towards idea of cutting a 0.8.1 patch for > instance that would rev only the spark component and get it out the door as > quick as possible so as to be as up to date with components and getting in > people's hands as quick as possible. > > If people don't like the idea of using patch number for something like > revving component.., alternative could be to just bump bigtop straight to > 1.0 next.., then conceptually would just do "minor" patch (ie: example of > bigtop 1.0 with component 0.5 , and bigtop 1.1 with component 0.6). This > might be appealing as I could see then patch versioning being leveraged for > things like added/fixed/enhanced tests or config tweaks >
