Rohit, Does packages from j.bac.o will have a -SNAPSHOT or -<date> suffix in packages and acs version from the API ? I don't think the suffix addition should be to user discretion but be there by default when using documented build procedure. also, if I compare to lot of other free software dev, the current working version is always pre release version number, as example for us: working on 4.5.0 would mean that the current version in pom.xmls would be 4.4.99 and at the release commit for GA, the version would be bump to 4.5.0.
I'm concerned on having a dev branch like 4.5 having pom.xml package(rpm/deb) version set to a non GA 4.5.0, because if somewone build is own RPMs or use those from j.bac.o, how can he know afterward that he is running on a non GA version ? over last months I've build and upgrade acs quite often from -SNAPSHOT to GA release, what I found is that if I upgrade rpms from ex: cloudstack-management-4.4.1-SNAPSHOT.el6.x86_64.rpm to cloudstack-management-4.4.1-1.el6.x86_64.rpm The safest upgrade path I've found so far: uninstall cloudstack-management + ... update url in /etc/yum.repo.d/cloudstack.repo yum clean all yum install cloudstack-management *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Tue, Oct 21, 2014 at 12:18 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi, > > > On 21-Oct-2014, at 9:40 pm, Nate Gordon <nate.gor...@appcore.com> wrote: > > > > Unfortunately maven's concept of multi-module projects requires that the > > sub projects define the version of the parent that they want. So it is > > scattered throughout all the pom files, but there is a handy maven plugin > > that can update them all for you. I think the bigger problem is around > the > > os packages and manual intervention. Which I think is solvable, but I've > > never attempted to use the scripts that have been mentioned. So I might > > need a little guidance as to the expected behavior, and what doesn't work > > now. Otherwise it seems like a solvable problem. > > I guess, we can write a script that adds custom prefixes to builds in > pom.xml; other than this the only places that may need tinkering are > packages/ and debian/changelog (also in upgrade paths, but we remove any > -SNAPSHOT stuff in them). > > For for master or 4.5.0, we keep the versions 4.6.0 and 4.5.0 > respectively; people who want custom suffixes can use a script (that > recursively goes to all packages/submodules and fixes pom.xml). People may > want to tag built rpms/debs which they can do either by adding suffixes to > those packages. We may also reintroduce having a plain text file that > holds git commit SHA out of which a build was built and put it in some > package like cloudstack-common (we had one of those before). > > > > > On Tue, Oct 21, 2014 at 8:42 AM, Pierre-Luc Dion <pdion...@apache.org> > > wrote: > > > >> 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 > >>> > >> > > > > > > > > -- > > > > > > *Nate Gordon*Director of Technology | Appcore - the business of cloud > > computing® > > > > Office +1.800.735.7104 | Direct +1.515.612.7787 > > nate.gor...@appcore.com | www.appcore.com > > > > ---------------------------------------------------------------------- > > > > The information in this message is intended for the named recipients > only. > > It may contain information that is privileged, confidential or otherwise > > protected from disclosure. If you are not the intended recipient, you are > > hereby notified that any disclosure, copying, distribution, or the taking > > of any action in reliance on the contents of this message is strictly > > prohibited. If you have received this e-mail in error, do not print it or > > disseminate it or its contents. In such event, please notify the sender > by > > return e-mail and delete the e-mail file immediately thereafter. Thank > you. > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > M. +91 88 262 30892 | rohit.ya...@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > Find out more about ShapeBlue and our range of CloudStack related services > > IaaS Cloud Design & Build< > http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > CloudStack Infrastructure Support< > http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training Courses< > http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based > upon its contents, nor copy or show it to anyone. Please contact the sender > if you believe you have received this email in error. Shape Blue Ltd is a > company incorporated in England & Wales. ShapeBlue Services India LLP is a > company incorporated in India and is operated under license from Shape Blue > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil > and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is > a company registered by The Republic of South Africa and is traded under > license from Shape Blue Ltd. ShapeBlue is a registered trademark. >
