www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Release planning for 2.063

reply Johannes Pfau <nospam example.com> writes:
As there were complaints about not having a release schedule for 2.062
and releases being made suddenly without no prior announcement, how
about planning the 2.063 release now?

2.062 was released ~7 weeks after 2.061. I think targeting 6 weeks
between 2.062 and 2.063 might be a good idea. The proposed days are
always Mondays. It doesn't really matter if the release is exactly on
that day but we should try to release in the week starting that Monday.

I propose to do the feature freeze next Monday (no more new features
after that). At the same time the first beta is released. Then 2 weeks
later first release candidate, one week later the next release
candidate and one more week to the final release:

Feature freeze     4 mar 2013
Beta 1             4 mar 2013
RC 1               18 mar 2013
RC 2               25 mar 2013
Final release      1 apr 2013 



If we decide to do minor releases after that release the dates could
look like this:

2.063.1
RC 1 	       5 apr 2013
RC 2 	       10 apr 2013
Final release  15 apr 2013 (2 weeks after 2.063.0)

2.063.2
RC 1           19 apr 2013
RC 2           24 apr 2013
Final release  29 apr 2013  (2 weeks after 2.063.1)
                            (and 2 weeks before 2.064.0)


A long term release plan could then look like this:
http://wiki.dlang.org/User:Jpf/Release_Schedule


Let's also try to switch to the new release process completely. As the
staging branch was criticized a lot and had only minor benefits I
updated the wiki page to remove the concept of the staging branch.
Most things stay the same, some get simpler. (If it's considered rude
to just edit the wiki page or if we want to keep staging branch I'm
sorry, just revert my changes)

http://wiki.dlang.org/Development_and_Release_Process

This would mean the next step is to create the 2.063 branch next
Monday:
http://wiki.dlang.org/Development_and_Release_Process#Preparing_a_new_major_release
Feb 25 2013
next sibling parent "Andrea Fontana" <nospam example.com> writes:
On Monday, 25 February 2013 at 18:47:21 UTC, Johannes Pfau wrote:
 As there were complaints about not having a release schedule 
 for 2.062
 and releases being made suddenly without no prior announcement, 
 how
 about planning the 2.063 release now?

 2.062 was released ~7 weeks after 2.061. I think targeting 6 
 weeks
 between 2.062 and 2.063 might be a good idea. The proposed days 
 are
 always Mondays. It doesn't really matter if the release is 
 exactly on
 that day but we should try to release in the week starting that 
 Monday.

 I propose to do the feature freeze next Monday (no more new 
 features
 after that). At the same time the first beta is released. Then 
 2 weeks
 later first release candidate, one week later the next release
 candidate and one more week to the final release:

 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013



 If we decide to do minor releases after that release the dates 
 could
 look like this:

 2.063.1
 RC 1 	       5 apr 2013
 RC 2 	       10 apr 2013
 Final release  15 apr 2013 (2 weeks after 2.063.0)

 2.063.2
 RC 1           19 apr 2013
 RC 2           24 apr 2013
 Final release  29 apr 2013  (2 weeks after 2.063.1)
                             (and 2 weeks before 2.064.0)


 A long term release plan could then look like this:
 http://wiki.dlang.org/User:Jpf/Release_Schedule


 Let's also try to switch to the new release process completely. 
 As the
 staging branch was criticized a lot and had only minor benefits 
 I
 updated the wiki page to remove the concept of the staging 
 branch.
 Most things stay the same, some get simpler. (If it's 
 considered rude
 to just edit the wiki page or if we want to keep staging branch 
 I'm
 sorry, just revert my changes)

 http://wiki.dlang.org/Development_and_Release_Process

 This would mean the next step is to create the 2.063 branch next
 Monday:
 http://wiki.dlang.org/Development_and_Release_Process#Preparing_a_new_major_release

April, 1st sounds like a joke :)
Feb 25 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 25 Feb 2013 19:47:19 +0100
Johannes Pfau <nospam example.com> wrote:

 As there were complaints about not having a release schedule for 2.062
 and releases being made suddenly without no prior announcement

I'm not sure where people are getting that idea. There's *always* prior notice: http://forum.dlang.org/post/5114B7A5.40102 digitalmars.com And that's been a regular thing for a least a couple years. Granted, there probably *should* be an additional announcement made on D.announce when a beta period starts. And the dmd-beta list *really* needs to be converted to a proper newsgroup. Having it as a mailing list is just ridiculous. But even things are, there certainly isn't "no prior announcement".
 I propose to do the feature freeze next Monday (no more new features
 after that). At the same time the first beta is released. Then 2 weeks
 later first release candidate, one week later the next release
 candidate and one more week to the final release:
 
 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013 
 

Scheduling RCs and finals is a bad idea, and so is locking the number of RCs. RCs and finals need to come *as* problems found with the beta and subsequent RCs are fixed. If that ends up taking more or less time than some completely arbitrary predetermined "fits all sizes" length of time, then so be it. What you're proposing is just scheduling for sake of scheduling. It's just arbitrary red tape, it doesn't help anything.
Feb 25 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 01:23, Nick Sabalausky wrote:

 I'm not sure where people are getting that idea. There's *always* prior
 notice:

 http://forum.dlang.org/post/5114B7A5.40102 digitalmars.com

Well, Walter decides at random that there's time for a new release and a beta is created. Then Walter needs to rush the release so much that it's like our lives depends on it and we get yet another release with regressions. -- /Jacob Carlborg
Feb 25 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/13 10:34 AM, Dicebot wrote:
 On Tuesday, 26 February 2013 at 15:29:55 UTC, Steven Schveighoffer wrote:
 That is more of a factor of the moratorium on changes while the
 release is being tested.

 I think if we branch the new development while a release is in
 progress, we shouldn't have this problem.

 -Steve

According to approved release process in wiki we already are supposed to do it. (Only other way around, branching new release without freezing master).

It has happened for the past 2-3 cycles already. Andrei
Feb 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 18:41, Andrei Alexandrescu wrote:

 It has happened for the past 2-3 cycles already.

Then why is it always such a rush to get form beta to release? -- /Jacob Carlborg
Feb 26 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/13 3:09 PM, Jacob Carlborg wrote:
 On 2013-02-26 18:41, Andrei Alexandrescu wrote:

 It has happened for the past 2-3 cycles already.

Then why is it always such a rush to get form beta to release?

So much to do, so little time... Andrei
Feb 26 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 26 Feb 2013 02:33:09 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-26 01:23, Nick Sabalausky wrote:

 I'm not sure where people are getting that idea. There's *always* prior
 notice:

 http://forum.dlang.org/post/5114B7A5.40102 digitalmars.com

Well, Walter decides at random that there's time for a new release and a beta is created. Then Walter needs to rush the release so much that it's like our lives depends on it and we get yet another release with regressions.

That is more of a factor of the moratorium on changes while the release is being tested. I think if we branch the new development while a release is in progress, we shouldn't have this problem. -Steve
Feb 26 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 26 February 2013 at 15:29:55 UTC, Steven 
Schveighoffer wrote:
 That is more of a factor of the moratorium on changes while the 
 release is being tested.

 I think if we branch the new development while a release is in 
 progress, we shouldn't have this problem.

 -Steve

According to approved release process in wiki we already are supposed to do it. (Only other way around, branching new release without freezing master).
Feb 26 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 26 February 2013 at 17:41:24 UTC, Andrei Alexandrescu 
wrote:
 It has happened for the past 2-3 cycles already.

 Andrei

Glad to hear it. Was not sure thus "supposed".
Feb 26 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 26 February 2013 at 22:39:13 UTC, Andrei Alexandrescu 
wrote:
 On 2/26/13 3:09 PM, Jacob Carlborg wrote:
 On 2013-02-26 18:41, Andrei Alexandrescu wrote:

 It has happened for the past 2-3 cycles already.

Then why is it always such a rush to get form beta to release?

So much to do, so little time... Andrei

So much to break.
Feb 26 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-02-25 at 19:47 +0100, Johannes Pfau wrote:
[=E2=80=A6]
 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013=20

I have yet to find an organization that used this sort of scheduling successfully. Feature freeze fine, beta 1 fine. RC is a release candidate not a beta. If no-one finds a problem with a release candidate it is relabelled the final release. Thus scheduling an RC2 is a failure of RC1 to be an RC at all. Successful releases will schedule a feature freeze and release a beta and push people to use it and report bugs. This entails getting is packaged and out via places like the D release page and the Debian package archive as snapshot releases. There might be a series of betas 2, 3, 4,=E2=80=A6 as required bug fixes are made, each getting a full snaps= hot release. Then an RC is declared which is a real RC not a wrongly labelled beta. Make the final release when it is ready to an approximate schedule not to a mandated day. Obviously the Debian model is one extreme: declare a freeze and then take well over a year to fiddle around and not update the rolling release thereby pissing off many people who ship over to Fedora. I am close to this point myself. Another extreme is to do what Eclipse does which is to simply release on a given date and then patch until the following year. This has a habit of annoying a lot of people as a release ends up having masses of annoying bugs that do not get fixed. Leading people to ship over to IntelliJ IDEA, Wing IDE, Code::Blocks, MonoDevelop. So schedule the freeze/beta then specify a date for the release candidate sequence to start and a moratorium period for an RC to be relabeled unless a problem is found. [=E2=80=A6]
 A long term release plan could then look like this:
 http://wiki.dlang.org/User:Jpf/Release_Schedule

I would suggest that having a schedule such as this is to lead to problems. It is overcomplicated and over-bureaucratic. If the intention is to move to timeboxing of the minor releases, just allow bug fix releases on an as needed basis. Allowing for s.XXX.Y is a good thing as it means there is a route for fixing trivial things instantly rather than waiting for the next minor release, but no need to schedule them. [=E2=80=A6] Moving to a timebox minor release program really necessitated putting effort into a Debian/Ubuntu/Mint repository, a Fedora repository, and a MacPorts/Brew repository, as well as Windows and OSX installers, ensuring the numbering scheme is monotonic increasing. If people can sign up to the programme using the systems packaging then take up is more likely(*). The point here is to be able to make it as easy as possible for *new* people to sign up. The current folks are hardcore people who will do stuff no matter how painful. The intention has to be to increase the D using community and this requires triviality of signup. Groovy/Grails/Gradle/Griffon (Gr8) community has gone a different route, necessitated by the slowness of the official Debian and Fedora release system and the unwillingness to support the variety of systems (though the MacPorts stuff always worked well). An individual "scratched an itch" and created a Bash/Vert.x based release and distribution system, called GVM. This has swept through the community (even Windows people) and is now the standard mechanism. New releases are available to all within hours and roll-back to any earlier release is trivial, as is having multiple releases co-resident. I strike me that a D/vibe.d system modelled on GVM, must be relatively straightforward. The question is not so much can vibe.d compete with vert.x in that part of the functionality, but can D compete with Bash in the client functionality. In particular can the client self update?(**) (*) I know Windows users do not understand having a system packaging infrastructure. (**) My irritation over GVM's use of bash is that it breaks my Bash initialization, so I have to hack it. But I am now happy my hack is sustainable so use GVM over Debian packaging for these Gr8 systems. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 21:05, Russel Winder wrote:
 On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote:
 […]
 *cough* DVM

1. I had forgotten about that :-( 2. Doesn't it only support DMD?

Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as DMD? -- /Jacob Carlborg
Feb 27 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-27 20:34, David Nadlinger wrote:

 There are »DMD-style« binary packages for LDC releases.

Right, I noticed that. Thanks, it would be a pain in the ass to have the tool building LDC/GDC. * Is there a central location for these releases? * Can I count on it being a new pre-compiled package there for every new release? * For which platform is the pre-compiled package available -- /Jacob Carlborg
Feb 27 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-27 22:17, Iain Buclaw wrote:

 Not built by myself, but there are many ways you can do it.  Eg:
 launchpad repository.

Are you referring to https://launchpad.net/gdc ? It would be nice to have pre-compiled self contained releases for all supported platforms. In the same style as DMD. -- /Jacob Carlborg
Feb 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 26 February 2013 at 04:46:12 UTC, Russel Winder wrote:
 On Mon, 2013-02-25 at 19:47 +0100, Johannes Pfau wrote:
 […]
 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013

I have yet to find an organization that used this sort of scheduling successfully. Feature freeze fine, beta 1 fine. RC is a release candidate not a beta. If no-one finds a problem with a release candidate it is relabelled the final release. Thus scheduling an RC2 is a failure of RC1 to be an RC at all.

+1
 I would suggest that having a schedule such as this is to lead 
 to
 problems. It is overcomplicated and over-bureaucratic. If the 
 intention
 is to move to timeboxing of the minor releases, just allow bug 
 fix
 releases on an as needed basis. Allowing for s.XXX.Y is a good 
 thing as
 it means there is a route for fixing trivial things instantly 
 rather
 than waiting for the next minor release, but no need to 
 schedule them.

+2
Feb 25 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 25 February 2013 at 18:47:21 UTC, Johannes Pfau wrote:
 As there were complaints about not having a release schedule 
 for 2.062
 and releases being made suddenly without no prior announcement, 
 how
 about planning the 2.063 release now?

 (rest skipped)

That's fine and long overdue thing. Judging by how D project is inertive (I believe Walter contributed mostly to this) I suggest that planning only release day (perhaps += beta) is enough and even such limited decision would be a significant step. The greater the plan is, the more likely it would not be followed. I can hadrly imagine Walter agreeing to release beta at specific day let alone some RC.
Feb 25 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 26, 2013 07:27:36 Maxim Fomin wrote:
 On Monday, 25 February 2013 at 18:47:21 UTC, Johannes Pfau wrote:
 As there were complaints about not having a release schedule
 for 2.062
 and releases being made suddenly without no prior announcement,
 how
 about planning the 2.063 release now?
 
 (rest skipped)

That's fine and long overdue thing. Judging by how D project is inertive (I believe Walter contributed mostly to this) I suggest that planning only release day (perhaps += beta) is enough and even such limited decision would be a significant step. The greater the plan is, the more likely it would not be followed. I can hadrly imagine Walter agreeing to release beta at specific day let alone some RC.

Aiming to make releases (particularly bug-fix releases) at some specific interval makes some sense, but all you can reasonably do with that is plan for when the next beta starts. When it makes sense for the actual release to happen depends entirely on what bugs there are - particularly if we stop ever doing a release with no regressions (which Brad keeps insisting on but Walter pretty much never does). Planning on how many RCs there will be or when they'll be or anything like that makes no sense at all. - Jonathan M Davis
Feb 25 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Monday, 25 February 2013 at 18:47:21 UTC, Johannes Pfau wrote:
 As there were complaints about not having a release schedule 
 for 2.062
 and releases being made suddenly without no prior announcement, 
 how
 about planning the 2.063 release now?

It looks like you just replaced the staging branch with a branch named after the release version. This is good as the current release should get patches until the next release anyway. I like the staging concept and that looks to be preserved. Onto the bad news. The automated test suite isn't really prepared for these changes, and I would consider it too valuable to move into a branching model where the release candidate isn't getting run. I did request the new processing be used on the beta announcement, but having remembered this I've changed slightly on pushing this. What we may want to do is bite the bullet for a single release so those involved can get a better understanding/feel for what is being proposed. But that is probably bad as there won't be followup to really iron out kinks.
Feb 25 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 26 February 2013 at 06:39:56 UTC, Jonathan M Davis
wrote:
 Aiming to make releases (particularly bug-fix releases) at some 
 specific
 interval makes some sense, but all you can reasonably do with 
 that is plan for
 when the next beta starts. When it makes sense for the actual 
 release to
 happen depends entirely on what bugs there are - particularly 
 if we stop ever
 doing a release with no regressions (which Brad keeps insisting 
 on but Walter
 pretty much never does). Planning on how many RCs there will be 
 or when
 they'll be or anything like that makes no sense at all.

 - Jonathan M Davis

Agree, planning beta and making release date to depend on it and opened bugs does make more sense.
Feb 26 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 25, 2013 22:39:42 Jonathan M Davis wrote:
 When it makes sense for the actual release
 to happen depends entirely on what bugs there are - particularly if we stop
 ever doing a release with no regressions (which Brad keeps insisting on but
 Walter pretty much never does).

LOL. I mean "particularly if we stop ever doing releases with any new regressions." What I typed was backwards. I really need to reread my posts more before posting them... - Jonathan M Davis
Feb 26 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Feb-2013 22:47, Johannes Pfau пишет:
 As there were complaints about not having a release schedule for 2.062
 and releases being made suddenly without no prior announcement, how
 about planning the 2.063 release now?

 2.062 was released ~7 weeks after 2.061. I think targeting 6 weeks
 between 2.062 and 2.063 might be a good idea. The proposed days are
 always Mondays. It doesn't really matter if the release is exactly on
 that day but we should try to release in the week starting that Monday.

 I propose to do the feature freeze next Monday (no more new features
 after that). At the same time the first beta is released. Then 2 weeks
 later first release candidate, one week later the next release
 candidate and one more week to the final release:

 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013

The more I see topics on release process the more I feel uneasy. Can't we just make releases more stable by doing 2 things instead: a) Provide nightly builds - same package as beta/release but as a weekly from Git master. b) List links to these and betas somewhere *prominent* damn it. *Separate* beta mailing list is *not* good enough. Post it on D, D.announce and somewhere else as well. Let people use them! The benefit is that both of these can be fully automated. What is already done is staging branch to avoid freezing the master. Betas are then just nightly builds for the staging branch and are provided few weeks before the release. So all of this already fits the current scenario. -- Dmitry Olshansky
Feb 26 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Mar-2013 18:18, Johannes Pfau пишет:
 Am Tue, 26 Feb 2013 21:46:45 +0400
 schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:

 The more I see topics on release process the more I feel uneasy.

 Can't we just make releases more stable by doing 2 things instead:

 a) Provide nightly builds - same package as beta/release but as a
 weekly from Git master.

Maybe this is useful if used additionally, but it can't replace betas or minor releases.

Yes, see below. Betas are nightlies published from frozen branches like staging.
 b) List links to these and betas somewhere *prominent* damn it.
 *Separate* beta mailing list is *not* good enough. Post it on D,
 D.announce and somewhere else as well. Let people use them!

Sure, this should be done anyway.
 The benefit is that both of these can be fully automated.

 What is already done is staging branch to avoid freezing the master.
 Betas are then just nightly builds for the staging branch and are
 provided few weeks before the release. So all of this already fits
 the current scenario.

We currently don't use release/version branches as it was described on the old wiki page though. At some point we'd have to start using those anyway and the staging branch is not really necessary anymore as the release branches can take the role of master. So I hoped those changes to the wiki page would make it easier to switch to the new process.

I posted these not to discourage the whole "wiki thing" but to illustrate a point that perhaps aiming for one step at a time changes (tweaks) is better. Then we can improve release process significantly without adding extra complication. -- Dmitry Olshansky
Mar 01 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 26 Feb 2013 04:45:56 +0000
Russel Winder <russel winder.org.uk> wrote:
 
 Groovy/Grails/Gradle/Griffon (Gr8) community has gone a different
 route, necessitated by the slowness of the official Debian and Fedora
 release system and the unwillingness to support the variety of
 systems (though the MacPorts stuff always worked well). An individual
 "scratched an itch" and created a Bash/Vert.x based release and
 distribution system, called GVM. This has swept through the community
 (even Windows people) and is now the standard mechanism. New releases
 are available to all within hours and roll-back to any earlier
 release is trivial, as is having multiple releases co-resident.
 
 I strike me that a D/vibe.d system modelled on GVM, must be relatively
 straightforward. The question is not so much can vibe.d compete with
 vert.x in that part of the functionality, but can D compete with Bash
 in the client functionality. In particular can the client self
 update?(**)
 

*cough* DVM
Feb 26 2013
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/25/2013 11:41 PM, Jesse Phillips wrote:

 Onto the bad news. The automated test suite isn't really prepared for these
changes, and I would consider it too
 valuable to move into a branching model where the release candidate isn't
getting run. I did request the new processing
 be used on the beta announcement, but having remembered this I've changed
slightly on pushing this.

You're somewhat out of touch / date. The auto testing system has been multi-branch aware for the last 2 releases.
Feb 26 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote:
[=E2=80=A6]
 *cough* DVM

1. I had forgotten about that :-( 2. Doesn't it only support DMD? 3. In moving from BitBucket to Git, support for 64-bit Linux appears to have been dropped. :-((((((((((( 4. Jordi's Debian repository is working well for 64-bit Debian just now for all the things he supports. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 26 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 27 February 2013 at 12:50:57 UTC, Jacob Carlborg 
wrote:
 On 2013-02-26 21:05, Russel Winder wrote:
 2. Doesn't it only support DMD?

Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as DMD?

There are »DMD-style« binary packages for LDC releases. David
Feb 27 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2013-02-27 at 20:34 +0100, David Nadlinger wrote:
 On Wednesday, 27 February 2013 at 12:50:57 UTC, Jacob Carlborg=20
 wrote:
 On 2013-02-26 21:05, Russel Winder wrote:
 2. Doesn't it only support DMD?

Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as=20 DMD?

There are =C2=BBDMD-style=C2=AB binary packages for LDC releases.

It would be really great if LDC and GDC had packages in D-Apt, along with DMD, Vibe.d, etc. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 27 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--485b397dd4fb3ade4904d6bb4e7e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Feb 27, 2013 12:56 PM, "Jacob Carlborg" <doob me.com> wrote:
 On 2013-02-26 21:05, Russel Winder wrote:
 On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote:
 [=85]
 *cough* DVM

1. I had forgotten about that :-( 2. Doesn't it only support DMD?

Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as DMD?

Not built by myself, but there are many ways you can do it. Eg: launchpad repository. Regards --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0'; --485b397dd4fb3ade4904d6bb4e7e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <p><br> On Feb 27, 2013 12:56 PM, &quot;Jacob Carlborg&quot; &lt;<a href=3D"mailto:= doob me.com">doob me.com</a>&gt; wrote:<br> &gt;<br> &gt; On 2013-02-26 21:05, Russel Winder wrote:<br> &gt;&gt;<br> &gt;&gt; On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote:<br> &gt;&gt; [=85]<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; *cough* DVM<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; 1. I had forgotten about that :-(<br> &gt;&gt;<br> &gt;&gt; 2. Doesn&#39;t it only support DMD?<br> &gt;<br> &gt;<br> &gt; Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as DMD?<b= r> &gt;</p> <p>Not built by myself, but there are many ways you can do it.=A0 Eg: launc= hpad repository. </p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </p> --485b397dd4fb3ade4904d6bb4e7e--
Feb 27 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 26 Feb 2013 04:45:56 +0000
schrieb Russel Winder <russel winder.org.uk>:

 On Mon, 2013-02-25 at 19:47 +0100, Johannes Pfau wrote:
 [=E2=80=A6]
 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013=20

I have yet to find an organization that used this sort of scheduling successfully. Feature freeze fine, beta 1 fine. RC is a release candidate not a beta. If no-one finds a problem with a release candidate it is relabelled the final release. Thus scheduling an RC2 is a failure of RC1 to be an RC at all.

Sorry for this late answer, I couldn't answer the last few days. You're probably right, my proposal is probably overzealous. I think we should at least schedule feature freeze but we should also try to schedule the final release. Of course if we find unexpected regressions the release can always be delayed, we might also release earlier if no issues pop up in the RC. I think scheduling the release date is important because if we do not schedule this we can get into similar situations as with the 2.061 release which was 5 months after 2.060 according to the changelog. If someone is just waiting for a minor fix which is already applied in git master it is unacceptable to wait 5 months for that fix only because there is no release date or because some other feature is not ready yet.
Mar 01 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 26 Feb 2013 21:46:45 +0400
schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:

 
 The more I see topics on release process the more I feel uneasy.
 
 Can't we just make releases more stable by doing 2 things instead:
 
 a) Provide nightly builds - same package as beta/release but as a
 weekly from Git master.

Maybe this is useful if used additionally, but it can't replace betas or minor releases.
 b) List links to these and betas somewhere *prominent* damn it. 
 *Separate* beta mailing list is *not* good enough. Post it on D, 
 D.announce and somewhere else as well. Let people use them!

Sure, this should be done anyway.
 The benefit is that both of these can be fully automated.
 
 What is already done is staging branch to avoid freezing the master. 
 Betas are then just nightly builds for the staging branch and are 
 provided few weeks before the release. So all of this already fits
 the current scenario.
 

We currently don't use release/version branches as it was described on the old wiki page though. At some point we'd have to start using those anyway and the staging branch is not really necessary anymore as the release branches can take the role of master. So I hoped those changes to the wiki page would make it easier to switch to the new process.
Mar 01 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 25 Feb 2013 19:23:35 -0500
schrieb Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>:

 On Mon, 25 Feb 2013 19:47:19 +0100
 Johannes Pfau <nospam example.com> wrote:
 
 As there were complaints about not having a release schedule for
 2.062 and releases being made suddenly without no prior announcement

But even things are, there certainly isn't "no prior announcement".

Yeah I didn't describe that very well. There usually is a "Shall we start a new beta" thread, then a new beta is started or sometimes not. But you only know at max 1 week before the feature freeze when it will happen and it also tells you nothing about the final release date. That is kind of "suddenly". Do you know _right now_ when 2.063 will be released or when there is a feature freeze? In 7 weeks as the timespan between 2.061 and 2.062? In 5 months (2.060/2.061) or 3 months (2.059/2.060) or when shared libraries are ready(feature based)?
 
 
 I propose to do the feature freeze next Monday (no more new features
 after that). At the same time the first beta is released. Then 2
 weeks later first release candidate, one week later the next release
 candidate and one more week to the final release:
 
 Feature freeze     4 mar 2013
 Beta 1             4 mar 2013
 RC 1               18 mar 2013
 RC 2               25 mar 2013
 Final release      1 apr 2013 
 

Scheduling RCs and finals is a bad idea, and so is locking the number of RCs. RCs and finals need to come *as* problems found with the beta and subsequent RCs are fixed. If that ends up taking more or less time than some completely arbitrary predetermined "fits all sizes" length of time, then so be it. What you're proposing is just scheduling for sake of scheduling. It's just arbitrary red tape, it doesn't help anything.

Granted scheduling RCs might be a bad idea. Having a _rough_ schedule for the release date (e.g. feature freeze + ~4weeks) can still be useful though to avoid blocking a release for months. Of course if new regressions are found another RC and postponing a release for 2 weeks wouldn't be bad.
Mar 01 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 26 Feb 2013 12:41:27 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 2/26/13 10:34 AM, Dicebot wrote:
 On Tuesday, 26 February 2013 at 15:29:55 UTC, Steven Schveighoffer
 wrote:
 That is more of a factor of the moratorium on changes while the
 release is being tested.

 I think if we branch the new development while a release is in
 progress, we shouldn't have this problem.

 -Steve

According to approved release process in wiki we already are supposed to do it. (Only other way around, branching new release without freezing master).

It has happened for the past 2-3 cycles already. Andrei

That's not the same thing though. The important part is the time span _between_ feature freeze and release. This is the time where the release is being prepared, regressions get fixed and no new features are accepted. More time between feature freeze and release should therefore lead to better tested releases and less stress for developers. According to the wiki process that time span would have been date of new release - date of old release = 7 weeks. The last pull request pushed to master included in the beta was https://github.com/D-Programming-Language/dmd/pull/1342 that was only 11 days before the actual release date so our feature freeze period was only 11 days.
Mar 01 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 26 Feb 2013 11:02:44 -0800
schrieb Brad Roberts <braddr puremagic.com>:

 On 2/25/2013 11:41 PM, Jesse Phillips wrote:
 
 Onto the bad news. The automated test suite isn't really prepared
 for these changes, and I would consider it too valuable to move
 into a branching model where the release candidate isn't getting
 run. I did request the new processing be used on the beta
 announcement, but having remembered this I've changed slightly on
 pushing this.

You're somewhat out of touch / date. The auto testing system has been multi-branch aware for the last 2 releases.

Does it automatically pick up new branches or does it require manual work?
Mar 01 2013