cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [PROPOSAL] Remove SNAPSHOT from versioning and keep tags on the release branch
Date Mon, 20 Oct 2014 16:45:33 GMT
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 <runseb@gmail.com> wrote:

>
> On Oct 20, 2014, at 6:07 PM, Nate Gordon <nate.gordon@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.yadav@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 <pdion891@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.yadav@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.gordon@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message