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.
