That's right Nate tech decisions (not releases) are open for everyone so thanks for your opinion.
I'd rather have the build process add the -SNAPSHOT then have it hardcoded in our sources. On Mon, Oct 20, 2014 at 6:38 PM, sebgoa <run...@gmail.com> wrote: > > 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. > > -- Daan
