[aerogear-dev] Maintenance branches

Lucas Holmquist lholmqui at redhat.com
Fri Mar 22 08:36:15 EDT 2013


Yes,  i like this way, 
On Mar 22, 2013, at 8:32 AM, Kris Borchers <kris at redhat.com> wrote:

> 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 at 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 at 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 at abstractj.org (mailto:bruno at 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 at gmail.com (mailto:daniel.bevenius at gmail.com) (mailto:daniel.bevenius at 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 at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org) (mailto:aerogear-dev at lists.jboss.org)
>> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > aerogear-dev mailing list
>> > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org) (mailto:aerogear-dev at lists.jboss.org)
>> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130322/2601b6bb/attachment-0001.html 


More information about the aerogear-dev mailing list