Rohit, I would much prefer something like Nate suggestions, at least when working with cloudstack build from git source is easy to know using the cloudstack version api call and rpm packages name.
Rohit, just be sure, what you are suggesting is ,as example, for branch 4.5 until 4.5.0 is GA, the version show would be 4.5.0 in the 4.5 branch, once 4.5.0 is GA, then code build from 4.5 branch would have 4.5.1. Compare to current where version is 4.5.0-SNAPSHOT until GA (GA commit would have 4.5.0), post GA: 4.5.1-SNAPSHOT. Correct? I thought the version label was define at one place , in a pom.xml , nowhere else. it's not the case in the code? I know it's not for the APIdoc which need to be manually defined. I guest it wouldn't be too complicated to have the version define at only one place and avoid to have a -snapshot inside the debian/changelog file. Nate, your help is very welcome, I'm not the proper person for how builds are currently setups, might have to look with Hugo for that. On Mon, Oct 20, 2014 at 1:29 PM, Erik Weber <terbol...@gmail.com> wrote: > On Mon, Oct 20, 2014 at 12:33 PM, Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > > > Hi, > > > > Background: > > > > Whenever we start on a new release and cut its release branch, for > example > > 4.5 branch, we add the -SNAPSHOT string to the version string in > pom.xmls, > > debian/changelog and elsewhere. Just this mere action adds a divergence > > between release and master branches and between two minor releases as > well. > > Also, we have seen build issue that come up just because someone forgot > to > > add or remove -SNAPSHOT or .snapshot in debian/ or packaging. The other > > issue is historically we keep release tags on the release branches, by > > doing this it makes it easy to find commits and follow the git history. > By > > doing a separate RC branch and then tagging on it is alright, you can > still > > do a git fetch and git checkout <tag> but it break the historic > convention. > > > > > > So, please share your views on the follow proposal that try to add simple > > changes: > > > > 1. Remove -SNAPSHOT suffix (and its lower/other case variants) from the > > source code, just change to next version and keep working on it; we don’ > > have to fix build systems often. > > > > 2. In future keep release tags on major release branch (for example, > > 4.3.0, 4.3.1 both on 4.3 branch) > > > > > > > Is it possible somehow (git foo or something?) to find out if a > tarball/branch is an official release? > I mean besides relying on the version number in POMs etc. > > As others I agree that having some sort of indication in the package wether > or not your install is an official release or not is important. > But it's only important to have some metadata about it, ie. the package > name or similar. > > So if we could improve the packaging to figure out a way to check if the > release is official or not, that would be sufficient for my use case. > > -- > Erik Weber >
