On Oct 20, 2014, at 6:07 PM, Nate Gordon <nate.gor...@appcore.com> wrote:
> 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 Just to clarify the voting process: Technically this is not a VOTE thread, ideally we try to avoid VOTE threads. If a [PROPOSAL] has a clear cut decision then there is no need for a VOTE. The only mandatory VOTE on the dev@ list is for releases. *anyone* can vote, committer or not, so you certainly have an official vote and you should make your opinion heard. As a community we actually need more of this. As per our bylaws [1] since you are not a committer, your vote will not be binding, but it certainly has some weight and we certainly should all welcome it. As a matter of fact, if you were to vote more and help enforce the decisions made, you would most certainly end up getting committer rights :) [1] http://cloudstack.apache.org/bylaws.html > 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.
