View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2013
Re: Release planning for 2.063
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
February 26, 2013
Re: Release planning for 2.063
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
February 26, 2013
Re: Release planning for 2.063
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).
February 26, 2013
Re: Release planning for 2.063
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
February 26, 2013
Re: Release planning for 2.063
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
[snip]

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
February 26, 2013
Re: Release planning for 2.063
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".
February 26, 2013
Re: Release planning for 2.063
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
February 26, 2013
Re: Release planning for 2.063
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.
February 26, 2013
Re: Release planning for 2.063
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?

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.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
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
February 26, 2013
Re: Release planning for 2.063
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
1 2 3 4
Top | Discussion index | About this forum | D home