Talk:Development and Release Process

This is a talk page. It is to be used for discussion of potentially controversial or otherwise large changes to the article itself.

• Please use the Add Topic link to start a discussion on a separate topic. Don't start a new topic inside an unrelated section, as it will only cause confusion.
• As a rule, it is considered bad form to edit somebody else's comments. Instead, post your reply to their comments immediately after.
• Please sign your comments with four tildes (~~~~) so that we know who said what.

Merge Proposed_new_D_development_process?

Hi deadalnix, it seems that we both created a page for the release process at the same time. :-) Should we merge in Proposed_new_D_development_process?—Quickfur (talk) 20:06, 13 December 2012 (CET)

Merged.—Quickfur (talk) 20:12, 13 December 2012 (CET)

Staging issue

Shouldn't be listed an issue about not having a clear idea of when the staging branch is deemed sufficiently-tested? RenatoUtsch (talk)

Please feel free to add it to the list. Oh also, please remember to sign your comments to that it's clear who said what. :-)—Quickfur (talk) 01:37, 14 December 2012 (CET)

Sorry, never used wikis, didn't know that the sign wasn't added by default. RenatoUtsch (talk) 01:45, 14 December 2012 (CET)

No problem, it's not very obvious for beginners, that's why I made the talk page boilerplate and stuck it to every talk page to remind users to sign.—Quickfur (talk) 01:50, 14 December 2012 (CET)

That is kind of hard to define precisely. I guess when the new feature have sufficient unittests and are passing according to review by community + when all regression bugs filled have been solved and all bug fixes from toher release have been merged. --Deadalnix (talk) 03:12, 14 December 2012 (CET)

Humm... yes, and we should establish some minimum time for the staging branch to exist, something like 4 months, to guarantee that the new features are sufficiently tested by the community. RenatoUtsch (talk) 15:39, 14 December 2012 (CET)

What about the overlap between release branches? Ideally, there should be some overlap, say 6 months to 1 year (depending on how much manpower we can garner for maintaining the releases) so that users have a transition period to migrate to potentially breaking changes in the language before the release they're using is no longer supported.—Quickfur (talk) 15:46, 14 December 2012 (CET)

sync official repos

I personally use dpl instead of official and usually pull from dpl into the corresponding branch on my local git. So I can rebase on localy without contacting the remote server multiple time. Is that worth putting here or the current presented workflow is better ? --Deadalnix (talk) 09:53, 14 December 2012 (CET)

You could add it as an alternative workflow, maybe? Or post it here first and let's compare them.—Quickfur (talk) 15:44, 14 December 2012 (CET)

Higher level discussion

We need to specify not only how will the git process be, but how the users will exactly see the releases being made too. For example, what guarantees we give with each release to the users? And how much time they will be supported? I don't have time to do this now, is someone able to? --RenatoUtsch (talk) 15:29, 14 December 2012 (CET)

We need, too, a model that adresses both users that want something stable and users that want to see the language evolve. The goals say something about that, but not explicitly. --RenatoUtsch (talk) 15:31, 14 December 2012 (CET)

I think Joseph Rushton Wakeling suggested on the forum that we overlap releases for 1 year, so that users have about 1 year to upgrade their codebases to a new release before the older release is no longer supported. Each release is supported for 3 years I think? But these are just example figures; we really need input from the core devs as to what actual timeframes are workable practically.—Quickfur (talk) 15:49, 14 December 2012 (CET)