cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Gordon <nate.gor...@appcore.com>
Subject Re: [PROPOSAL] Remove SNAPSHOT from versioning and keep tags on the release branch
Date Mon, 20 Oct 2014 16:07:46 GMT
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.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.

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