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)

But to define that we need to define first the time that a stable release will be supported. For example, it makes no sense to overlap release branches for 1 year if they are released every 2 years. Ideally, I think each stable release should be supported for 3 years, with about 1 year of overlap. And non-breaking new features should go to D2.N.M versions. Actually, on the D2.N.M model we are propposing on the page, the N version will be mantained for how long? Because if is really 3 years, non-breaking new features must enter the M version, only when release branches are overlapping that no new features must be added. RenatoUtsch (talk) 15:54, 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)

FWIW I think the usual name for 'official' is 'upstream'. But that's just bikeshedding. I usually do it this way (after adding upstream as remote):

git checkout master
git pull --ff-only upstream master
git checkout myfeaturebranch
git rebase master

This way, my local master is always in sync with upstream, and the feature branch rebase is done w.r.t. to a local branch, so it's probably easier to cleanup if anything goes wrong.—Quickfur (talk) 17:10, 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)

Yes, exactly. 3 years looks good, more than that is too much time, there will be too much breaking features if each stable release is made in more than 3 years. And yes, we need to ask the core devs, they will be managing the time, not us. RenatoUtsch (talk) 15:56, 14 December 2012 (CET)

GitHub

The current draft doesn't seem to consider GitHub or anything beyond doing stuff on a local machine. D's development is very much centered around using GitHub for collaboration. I think the release process needs to keep how GitHub is used with D in mind as it is drafted. Eco (talk) 18:38, 14 December 2012 (CET)

New branch creation

Just a minor note that lines like git "checkout staging; git checkout -b 2.N+1.0;" can be done using "git checkout -b 2.N+1.0 staging" Eco (talk) 18:41, 14 December 2012 (CET)