Jump to page: 1 24  
Page
Thread overview
Release planning for 2.063
Feb 25, 2013
Johannes Pfau
Feb 25, 2013
Andrea Fontana
Feb 26, 2013
Nick Sabalausky
Feb 26, 2013
Jacob Carlborg
Feb 26, 2013
Dicebot
Feb 26, 2013
Dicebot
Feb 26, 2013
Jacob Carlborg
Feb 27, 2013
deadalnix
Mar 01, 2013
Johannes Pfau
Mar 01, 2013
Johannes Pfau
Feb 26, 2013
Russel Winder
Feb 26, 2013
deadalnix
Feb 26, 2013
Nick Sabalausky
Feb 26, 2013
Russel Winder
Feb 27, 2013
Jacob Carlborg
Feb 27, 2013
David Nadlinger
Feb 27, 2013
Jacob Carlborg
Feb 27, 2013
Russel Winder
Feb 27, 2013
Iain Buclaw
Feb 28, 2013
Jacob Carlborg
Mar 01, 2013
Johannes Pfau
Feb 26, 2013
Maxim Fomin
Feb 26, 2013
Jonathan M Davis
Feb 26, 2013
Maxim Fomin
Feb 26, 2013
Jonathan M Davis
Feb 26, 2013
Jesse Phillips
Feb 26, 2013
Brad Roberts
Mar 01, 2013
Johannes Pfau
Feb 26, 2013
Dmitry Olshansky
Mar 01, 2013
Johannes Pfau
Mar 01, 2013
Dmitry Olshansky
February 25, 2013
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
February 25, 2013
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 :)
February 26, 2013
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.

February 26, 2013
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.

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,… as required bug fixes are made, each getting a full snapshot 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.
[…]
> 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.

[…]

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.

-- 
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
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
February 26, 2013
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.
February 26, 2013
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
February 26, 2013
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
February 26, 2013
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.
February 26, 2013
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.
« First   ‹ Prev
1 2 3 4