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@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@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-Versioning-Policy-td1914.html

--
"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@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@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@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@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@lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev