cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@shapeblue.com>
Subject Re: [PROPOSAL] Remove SNAPSHOT from versioning and keep tags on the release branch
Date Mon, 27 Oct 2014 07:10:01 GMT
Hi Hugo and Nate,

I look forward to your comments on my replies on this thread. If we’re in agreement, I would
like to start a voting thread.

Regards.

> On 23-Oct-2014, at 3:03 pm, Hugo Trippaers <hugo@trippaers.nl> wrote:
>
> 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.
>

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