I definitely think branches are necessary. Just from my experience with jQuery, this has
worked well.
When a new stable, minor version is released, a branch is created for it. So we would
create a 1.0-stable branch or something like that. When bugs are fixed, they are fixed in
master, then cherry-picked over to the current stable branch. When we are ready for a
patch release (1.0.1 for example), that can be tagged directly from the 1.0-stable branch
and all of those bug fixes already exist in master.
In the meantime, new features (Notifier for example) are developed in a feature branch
(currently we are doing that in the Notifier branch). Those branches occasionally have
master merged into them to keep them up to date. Then, when we are ready to add a feature
to the next release, the feature branch is merged into master. Then, based on our
versioning policy, we create a new minor or major release by first creating a new stable
branch (1.1-stable or 2.0-stable depending on what we're releasing), tag the release
from that new branch, then delete the old stable branch.
I really like this method because it allows for simultaneous new development and
maintenance and easily keeps all branches and releases up to date with latest bug fixes.
Thoughts?
On Mar 22, 2013, at 7:22 AM, Daniel Passos <daniel(a)passos.me> wrote:
IMO tags work fine.
I don't think a branch is necessary. If we have something to fix, we create a
temporary branch, fix, merge to master and create a tag for it
Daniel Passos
On Fri, Mar 22, 2013 at 7:03 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hi Dan, I believe that we will stick with the following approach
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-RFC-Initial-Versio...
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Friday, March 22, 2013 at 6:57 AM, Daniel Bevenius wrote:
> > I'm not sure if we really need branches, maybe just tags?
>
> Not sure how that would work but I'd be interested to learn. I could not
determine just by looking at the torguebox repo as then have branches for what looks like
maintenance/dev releases (and also tags of course)
> As long as we all do the same I'm happy.
>
>
>
> On 22 March 2013 10:23, Bruno Oliveira <bruno(a)abstractj.org
(mailto:bruno@abstractj.org)> wrote:
> > I'm not sure if we really need branches, maybe just tags?
https://github.com/torquebox/torquebox for example has been working with tags, branches at
least to me might lead to confusion.
> >
> >
> > --
> > "The measure of a man is what he does with power" - Plato
> > -
> > @abstractj
> > -
> > Volenti Nihil Difficile
> >
> >
> >
> > On Friday, March 22, 2013 at 6:18 AM, Sebastien Blanc wrote:
> >
> > > +1 to create a 1.0.0 branch
> > > For 1.0.1 not sure if it has to be also branch or just the master
otherwise Master should be for 1.1 stuff ?
> > > Seb
> > >
> > >
> > >
> > > On Fri, Mar 22, 2013 at 10:12 AM, Daniel Bevenius
<daniel.bevenius(a)gmail.com (mailto:daniel.bevenius@gmail.com)
(mailto:daniel.bevenius@gmail.com)> wrote:
> > > > Hi all,
> > > >
> > > > I'd like to discuss how to handle maintenance branches. Sorry if
this has already been discussed, I think Kris posted something about this but I was not
able to find it.
> > > >
> > > > For example, now that we are about to release 1.0.0 we will tag that
release. After that should we create a 1.0.1 branch for patches/bugfixes and then continue
with new features in master?
> > > >
> > > > Since we are in a waiting state at the moment, which could happen
again, should we perhaps create a branch named 1.0.0, which we can use until the release
and then tag it and remove that branch. After that any issues would be fixed in the 1.0.1
branch.
> > > >
> > > > Does this sound correct?
> > > >
> > > > Thanks,
> > > >
> > > > /Dan
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
(mailto:aerogear-dev@lists.jboss.org)
> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
(mailto:aerogear-dev@lists.jboss.org)
> > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev