Keep in mind there is a maven issue here. It is mainly in the devs env so not really important there but in a operators lab like Pierre-Luc's it is an added inconvenience. Like him I won't -1. It would solve what I have been solving with rc branches of the release branch.
On Mon, Oct 20, 2014 at 3:26 PM, Pierre-Luc Dion <pdion...@apache.org> wrote: > When working with multiple environments with various installation of > Cloudstack (in labs) the -SNAPSHOT tell me that it's the non released > version currently running. That's helpful once the release is GA to know > if's the the GA version in place or not. > > Having the -SNAPSHOT remove the confusion around if the code is from a GA > version. I would tend to say that -SNAPSHOT should be all over the place > except official release tags, .tgz or packages. > > I would be -0 close to a -1 if this is a vote, but I might misunderstand > something. I'd like the know what we are trying to resolve? if this is > because if cause issue with jenkins jobs, and what so ever then it's fine. > I will not -1 this ;-) > > PL > > > On Mon, Oct 20, 2014 at 8:04 AM, sebgoa <run...@gmail.com> wrote: > > > > > On Oct 20, 2014, at 12:35 PM, Wido den Hollander <w...@widodh.nl> wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 10/20/2014 12:33 PM, Rohit Yadav 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) > > >> > > > > > > +1 from my side. It breaks the Debian/Ubuntu packaging quite often and > > > I don't see any benefit from the -SNAPSHOT versioning. > > > > > > > I don't recall while the SNAPSHOT is needed (aside from showing that this > > is not an official release), but having release 4.3.1, it was more of a > > pain then a help. Plus the release build script does not handle the > version > > change properly, and the packaging changelog need to be changed manually. > > > > So +0 with a bias towards +1 if this does not break ASF policy. > > > > > > > > > > Wido > > > > > >> > > >> > > >> 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. > > >> > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1 > > > > > > iQIcBAEBAgAGBQJUROViAAoJEAGbWC3bPspCMjQP/Rk+vUQzqLuuvuBNJsxTDmvA > > > qSunDElNH/FlNauLPjBI4yFN/0U5fF0wyNo1TT9DKvEXqC8CLVedabw6AnXiB5M7 > > > Tq4H/pcGk5wy7SiO/ujbWqybfFTETfqSFsx8da6t2liGLU7xpqRF7mY2qJYee+Fl > > > 5nayH6qUlmSVWYJQIZ814VsExmflPwrM86KdcB7spK7b/FHVns14PdpDxWVPSKYu > > > DA1cIPw6d+juYhsiz4jOErwc4EoftjgKvxq3Pqeg94CIe7mn5CY+Rj83Golnbw7x > > > NdWWsztCMne1LuKKDn1WFwmqCurt/QxwtDHmkF329QYDZ3ChMkotiDdjBBIKN026 > > > eXm3ZIj2SNyUA73OlVK5av+2ivEJ4E10LP5/GmToTLi9buzJWcx+Q7XqbIRZMOOO > > > H4Sv97ww3WgooIPGxKdxB68sgVxbVsSHzYwereWM8LPjQatQL2FKuqmW/I8rSIcT > > > O/3IrbmsPJhIAVeBKkpVVASmABp52vm3aCXWkFD8muqHcYGjkxiECusLfTFkkxt6 > > > mfulKCsDSh07BBGG7Mb+xru+q9uEn45J5F+FbvpOpe0lOOlrrzyk2oBd2Imm8KeF > > > kMk403f236zML73sKL3zapLWfaNy+itsVHSNR1vSbB73+OKUWCpvOao/lyQ0rNk1 > > > HMaANeRqibyJA+FHajZr > > > =CNBu > > > -----END PGP SIGNATURE----- > > > > > -- Daan
