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.ya...@shapeblue.com> wrote: > > Hi, > >> On 22-Oct-2014, at 7:12 pm, Pierre-Luc Dion <pd...@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.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.
