cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <h...@trippaers.nl>
Subject Re: [PROPOSAL] Remove SNAPSHOT from versioning and keep tags on the release branch
Date Thu, 23 Oct 2014 09:33:16 GMT
I’m -1 on dropping the SNAPSHOT tag.

Snapshots are an integral part of maven building the project. A snapshot is mavens way of
telling that a particular release is still in development and causes different behavior in
how it resolves artifacts. For a developer working only local the problem could be minimal
and in case of problems he could wipe his .m2 directory. However for people using centralized
maven repositories it could cause unintended behavior if snapshot is dropped as maven states
that repositories should never replace an artifact that is pushed as a release artifact (without
-SNAPSHOT).

The net result of this could be that developers are recompiling a build, but actually running/testing
a completely different version because the repository was not refreshed because a release
version already exists. I would propose to keep the -SNAPSHOT until we have a version that
we actually want to release to the public. Personally i would even be in favor of naming a
RC something like 4.4.99-SNAPSHOT until we push the final build, but that would interfere
with the way we sign and mark releases.

I wouldn’t mind dropping -SNAPSHOT in packaging scripts or anything else that happens with
the source after we finish working on it, but i would like not to have anything without -SNAPSHOT
in our git unless its a final release (or RC in our current way of working).

Cheers,

Hugo



> On 23 okt. 2014, at 16:31, Rohit Yadav <rohit.yadav@shapeblue.com> wrote:
> 
> Hi,
> 
>> On 22-Oct-2014, at 7:12 pm, Pierre-Luc Dion <pdion@cloudops.com> wrote:
>> 
>> Does packages from  j.bac.o  will have a -SNAPSHOT or -<date> suffix in
>> packages and acs version from the API ?
> 
> If you add -SNAPSHOT, -date or any suffix it will be packages names (the deb/rpm file
etc) but no in version returned from API (I think version info in API/DB should be something
like 4.4.1 and not 4.4.1-SNAPSHOT)
> 
>> I don't think the suffix addition
>> should be to user discretion but be there by default when using documented
>> build procedure. also, if I compare to lot of other free software dev, the
>> current working version is always pre release version number, as example
>> for us:  working on 4.5.0 would mean that the current version in pom.xmls
>> would be 4.4.99 and at the release commit for GA, the version would be bump
>> to 4.5.0.
> 
> Regarding 4.4.99-> 4.5.0 etc, this is entirely different versioning scheme. I’m
not proposing to change versioning conventions, just that we remove -SNAPSHOT if we don’t
really need it.
> 
> To differentiate between GA and other releases, other ways of adding suffixes on package
names (such as filenames of the deb/rpm packages, or filenames of tarballs etc) can be used.
> 
>> I'm concerned on having a dev branch like 4.5 having pom.xml
>> package(rpm/deb) version set to a non GA 4.5.0, because if somewone build
>> is own RPMs or use  those from j.bac.o, how can he know afterward that he
>> is running on a non GA version ?
> 
> I see j.bac.o only for test builds and not for production, because you’re right we
don’t know if it was GA or some other build. What we can do is, we store the git SHA used
for building/packaging in cloudstack-common package in a text file. So, in future if someone
is not sure they can read the SHA and compare if it was GA or not.
> 
> ShapeBlue is going to release a public CloudStack repo/systemvmtemplate/doc etc. hosting
for everyone soon. It tries to solve the information issue for users, for example people don’t
know which deb/rpm version/build they installed and they may not know what git SHA or tag
was used to build them, or if it was GA/official-release or patched.
> 
> 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.


Mime
View raw message