cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: too long to package a release?
Date Wed, 02 Jan 2013 21:58:13 GMT
On Wed, Jan 2, 2013 at 1:45 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> I am happy enough to have features be worked on in branches etc, I just
> think that it should be flipped and the stable release be the branch and
> dev to be on master.
>
>
> As a separate issue, I would suggest not using branches to "name" point
> releases, but just tag them.  If you have a 2.3.0 release, and you need to
> fix a bug in 2.3.1, those should not become two logically separate code
> branches with independent dev, but rather they are a logically single
> timeline with many names for each historically significant commit, right?
>  Thats what tags are for (http://git-scm.com/book/en/Git-Basics-Tagging).

If we do dev in master, we run into a situation where master has stuff
that we're not comfortable springing on someone for a point release.
For example, when we did CordovaWebView, we committed that in 1.9, but
we needed to do a 1.8.1.  Introducing CordovaWebView was already bad
enough in a major release but doing that in a point release would have
been completely ridiculous and our users would be asking for all our
heads instead of just mine!  Therefore, we created a 1.8.x branch and
did 1.8.1 on that branch instead of the master.

I think point releases should exist in the major releases branch.
That way 1.8.0 will have tags for 1.8.0, 1.8.1 and so forth.
Furthermore, it may not make sense to merge this back to master for
certain cases, because the code may not exist in the next release.

Mime
View raw message