I'll chime in from a purely build engineer/maven user perspective. Adding -SNAPSHOT to the version indicates a certain perspective on the part of the build system. If you are using a system like Artifactory to store the output artifacts it allows tracking how many snapshot versions to keep, if snapshots are allowed in a specific repo (release repo vs. snapshot repo), etc. In general, there should only ever be one artifact that is the pure number, instead of -SNAPSHOT, -rc*, etc. Otherwise it is difficult to quickly track down exactly what build/code/foo generated the artifact you are looking at. Yes you can embed all sorts of things in the package itself, but that requires pulling the package apart to inspect. In a previous environment I had Bamboo and Artifactory setup to handle the release process, and it fully managed the versioning as part of that. One click process to go from snapshot to release, and set the dev branch to the next snapshot version.
If there are problems with the release/build process, I would say that we should fix those instead. I would be happy to do some work on that, even if it is Maven. It is the more technically correct way to do it, and there are benefits if done correctly. I realize that I don't have an official vote on this, but I would lean towards a -1 on the first item with the intent to help fix the root cause of why this proposal exists. But I don't want to resist change if the community doesn't find it useful. Thanks, -Nate On Mon, Oct 20, 2014 at 9:00 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi Pierre, > > Thanks for sharing. I think in your use case, if you’re using debian > packages you can take the source and add a package release with suitable > names in debian/changelog; in case of rpms you can add a tag/build-version > (like 4.4.1.20141020). What I’m proposing is to remove using -snapshot > suffix in pom.xmls and in debian/changelog by default. If anyone want that > convention, they can run a script to do that automatically as well. This > tries to reduce code divergence, the effort it take to find/fix build > issues say when building deb/rpm packages, especially between version > changes. > > > On 20-Oct-2014, at 6:56 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 ;-) > > 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. > -- *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.
