[Rails-devel] Release strategy (was: Rails 1.5.1 available)

[Erik V. <eri...@xs...>]

With Brett, I would prefer to see release tags in the master branch, so we
can see what's in a release. But I have no serious problems with Stefan's
approach if he is convinced that it's better.

For completeness sake, just one more remark: IMO 3rd-digit releases should
not be reserved for bug fixes only. Small improvements, and perhaps even not
so small ones, should be included as well.  I have a feeling that our users
are much better testers than that we are, so withholding updates until we
think these are really stable might backfire.  I'd rather have a bug
reported sooner than later.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 10, 2011 8:14 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails 1.5.1 available
> 
> >
> > It's far more important to me that each release is accessible from the
> > repo. How it achieves that is totally negotiable.
> >
> > Personally, because you and Erik are far more active in the project
> > than I am, I'm willing to give your preferences a bit more weight than
> > mine. ;-)
> >
> > IMO, it's easier to leave master as the lineage of stable changes and
> > do any new development in (usually local) branches that can be merged
> > into the stable trunk when they're ready.
> >
> > In git, branches and tags are both very very cheap (and fast), unlike
> > SVN. So, if you want to have all development happen in master, then
> > branch off for stable releases, we can do that too.
> 
> I understood that for Erik the latter is the preferred choice. And I do
not mind
> to manually pick the fixes into a separate branch at the time of release.
> So everyone can contribute simply to the master and does not have to care
if
> where to push depending if it is a bug-fix or a new development. The only
> thing to ensure is that the master branch compiles and runs after each
> commit.
> 
> Substantial changes have still should be done inside separate branches,
like
> my start of refactoring some parts in the Rails 2.0 branch.
> Stefan
> 
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel