cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: [PROPOSAL] Remove SNAPSHOT from versioning and keep tags on the release branch
Date Mon, 20 Oct 2014 17:29:45 GMT
On Mon, Oct 20, 2014 at 12:33 PM, Rohit Yadav <rohit.yadav@shapeblue.com>
wrote:

> Hi,
>
> Background:
>
> Whenever we start on a new release and cut its release branch, for example
> 4.5 branch, we add the -SNAPSHOT string to the version string in pom.xmls,
> debian/changelog and elsewhere. Just this mere action adds a divergence
> between release and master branches and between two minor releases as well.
> Also, we have seen build issue that come up just because someone forgot to
> add or remove -SNAPSHOT or .snapshot in debian/ or packaging. The other
> issue is historically we keep release tags on the release branches, by
> doing this it makes it easy to find commits and follow the git history. By
> doing a separate RC branch and then tagging on it is alright, you can still
> do a git fetch and git checkout <tag> but it break the historic convention.
>
>
> So, please share your views on the follow proposal that try to add simple
> changes:
>
> 1. Remove -SNAPSHOT suffix (and its lower/other case variants) from the
> source code, just change to next version and keep working on it; we don’
> have to fix build systems often.
>
> 2. In future keep release tags on major release branch (for example,
> 4.3.0, 4.3.1 both on 4.3 branch)
>
>
>
Is it possible somehow (git foo or something?) to find out if a
tarball/branch is an official release?
I mean besides relying on the version number in POMs etc.

As others I agree that having some sort of indication in the package wether
or not your install is an official release or not is important.
But it's only important to have some metadata about it, ie. the package
name or similar.

So if we could improve the packaging to figure out a way to check if the
release is official or not, that would be sufficient for my use case.

-- 
Erik Weber

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