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)

Well, most of the work is done on the local machine anyway. The only time GitHub factors into the equation is when you're pulling from upstream, or pushing a feature branch to your GitHub fork in order to send a pull request. The actual coding, testing, branching, etc., is usually just done on your local machine.—Quickfur (talk) 00:36, 15 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)

Feel free to edit those lines; I've replaced a few of those myself. It's not a big deal though, just a matter of familiarity with git's various shortcuts.—Quickfur (talk) 00:37, 15 December 2012 (CET)

staging branch

What is the point of the staging branch? Looking at it I'd say it appears to have a similar function as the git-flow model's "master" branch. The point of that is to always have a branch that represents the current public release. That way you can branch hotfixes off of it quickly if you need to fix something quickly. I've found it mostly unnecessary myself if you are tagging properly but I can see why some people would like it.

If that is the goal of "staging" I think the approach has some unnecessary steps that make it more complicated than it needs to be. Instead of making a release branch from staging you make one from master ("develop" in git-flow parlance). You then work from the release branch (not from master) as you making changes relevant to getting the release out (version number bumps, last minute fixes, etc.). Then once the release branch is done you merge (no-ff) it to staging and master, tag staging with the version number, and delete the release branch. Staging always represents the latest public release.

Making release commits to master and merging into the other branches (staging and the release branch) is kind of pointless and defeats the purpose of having those branches in the first place. Master should be free to take commits for the next version as soon as the release branch is created.

Also, I think release branches should use the prefix "release" so that they aren't confused with version tags. Eco (talk) 19:19, 14 December 2012 (CET)

No. The staging branch is the step when you freeze the development branch to do only bugfixes, to make the branch stable before doing an actual release. Then, what would differ from the git-flow is that there will be a separate branch for each release, and not on master. This will allow mantaining different releases on the overlap period.

For example, say that we are releasing the 2.N version. We merge the master branch (that contains the latest development) into staging and block any addition of new features. The staging branch will be there for, say, 4 monthes, only fixing bugs and testing the new features. After that time, a 2.N branch will be made with the contents of the staging branch and the tag 2.N.0 should be made on top of that. Bugfixes for the 2.N.1 version should be made on this branch.

Then, say, after 2 and a half years the master branch will be merged again in staging, and the process starts another time. But note, when the 2.N+1 version is released, it will be on the branch 2.N+1, and the 1 year period of bugfixes for the 2.N can still be done in the 2.N branch without confusion.

So, maybe the staging branch shouldn't exist in the 2.5 years period between each new stable release. Any idea? Maybe the 2.N branch should work as the staging branch for that release, so it would not be needed, and the tag 2.N.0 should mark when the release was really made after stabilization. What do you think? RenatoUtsch (talk) 23:25, 14 December 2012 (CET)