github release procedure

Johannes Pfau nospam at example.com
Fri Jan 4 09:17:53 PST 2013


Am Fri, 4 Jan 2013 08:31:57 -0800
schrieb "H. S. Teoh" <hsteoh at quickfur.ath.cx>:

> On Fri, Jan 04, 2013 at 08:18:52AM -0800, Jonathan M Davis wrote:
> > On Friday, January 04, 2013 15:26:20 deadalnix wrote:
> > > It is why the proposal include branches as 2.N and revision as
> > > 2.N.M . So the same version of D, with bugfixes can be published.
> > > 
> > > The branch has a 2.N form, the tag has a 2.N.M form.
> > 
> > And why would that particular bug get a release as opposed to
> > another?

I would propose to only merge regression fixes into minor releases. At
least for dmd every bug fix also has potential to break user code. I
think if 2.061 compiled some code, 2.061.1 should as well and the only
way to ensure that is by only merging regression fixes (regressions
which started to occur in 2.061).

The decision what fixed bug / regression justifies an immediate release
is up to the release manager. But to make things simple we can just
have a fixed schedule for less urgent fixes: release a update every x
weeks.


More information about the Digitalmars-d mailing list