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)

An easy option is to slow down how many new release are done for new feature and release them by pack. --Deadalnix (talk) 22:59, 16 December 2012 (CET)

That is a ridiculously long time for staging. Granted I'm looking at having two releases being handle, but discussion seems centered around only stable releases. We should be looking to have a release following the current frequency (about once a month). I expect this to make for continual testing of new features by the community and will thus reduce the need for a long staging of the stable release. (PS this sucks as a discussion forum) he_the_great (talk) 18:32, 14 December 2012 (PST)

I don't think 4 months are a ridiculously long time for staging if the release is made every 3 years. Anyways, what do you suggest? RenatoUtsch (talk) 13:56, 15 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)

This is also what I do. --Deadalnix (talk) 23:01, 16 December 2012 (CET)

The thing is that I could carry on for ages about git stuff. I wanted to keep it short and to the point; it certainly was not a matter of "do it this way or die!" I/you could go in and expand it if people think it needs to be? Infiltrator (talk) 04:41, 17 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)

If anyone read this, read the comment I made on the "Expanding LTS" topic, I describe this idea better with some improvements. RenatoUtsch (talk) 14:17, 15 December 2012 (CET)

I don't think that the naming really matters. Whether we do "maint" -> "master" -> "next" or "release-blah" -> "release-blah+1" -> "staging" doesn't make a difference, so long as it's all documented somewhere easily accessible. Infiltrator (talk) 04:45, 17 December 2012 (CET)::

Expanding LTS

We should plan a expanding LTS, that is start with a short timeline and expand it on subsequent releases. I'm going to start on the "end-user" view and describe what I envision but don't expect it to stick. he_the_great (talk) 18:55, 14 December 2012 (PST)

I have come with a good idea for the release schedule. Say that we are 3 or 4 monthes before the next LTS release. We need to branch the staging branch in a 2.N (put the contents of the staging branch in the 2.N branch) branch, where N is the new LTS version. Then, no other features can be included in this 2.N branch, only bugfixes are allowed. This period will have one RC every month (?) with the latest fixes in the 2.N branch. After the 3 or 4 monthes period we'll tag the 2.N.0 release. After every 4~6 monthes, we'll release a new 2.N.x version with the latest bugfixes in the 2.N branch, but with no additional features (including non-breaking features here will just be more work to the devs, I don't think it is a good idea). While these bugfix releases are being made, every feature that stabilizes enough in the master branch is merged into the staging branch, where the feature shouldn't have much breaking changes (although changes are still allowed, the branch is not frozen). Every 3 monthes, dev releases are made with these features that made their way into the staging branch. This is done while the fixes in the 2.N branch are made. Then, 4 monthes prior to the next LTS release, a new 2.N+1 branch will be created with the staging branch contents. The cycle will repeat, these 4 monthes will have no additional features on the 2.N+1 branch, and neither on the next 3 years. This organization, in dev and LTS releases, will allow releases for the ones that want a stable environment to develop (the LTS releases) and the ones that want the latest great features from D will have a somewhat stable environment (the dev releases, somewhat like the ones we have now, maybe a little more stable) to use. On top of that, the staging branch will never be frozen, so development will never stop, as someone was saying on the forums that was a bad idea. And, when the new LTS release is made (2 years after the older LTS), the older LTS will be mantained for more one year, what means that each LTS will be mantained for 3 years. What do you think? RenatoUtsch (talk) 14:14, 15 December 2012 (CET)

I'm pretty sure I already wrote this down for the "release schedule." You are throwing in many version numbers but not a version number for the dev releases.

I think not freezing the staging branch would be a mistake. I do not see what that accomplishes over the development branch (master). If we wanted to branch into a release branch and stabilize there, great that is pretty much what I see the staging branch as anyway (it is only a point in time for the release).--He the great (talk) 20:22, 16 December 2012 (CET)

The staging branch would almost all the time be used to stabilize things, only when we are next to release a new stable version we would branch into a new release branch to make a final stabilization, and new features would be still allowed to enter the staging branch. What I am trying to describe is a process where you have a stable release branch that has years of support and a branch that is not as unstable as master that you can make builds for the users that want the new features, but without a completely unstable environment. If we made something as Master > Staging (every 3 monthes a new version comes from here, for the latest changes in the language) > 2.N+1 (this will only happen every 1 year and 8 monthes, when we are releasing a new stable version). The problem with the 2 user groups in D would be solved. RenatoUtsch (talk) 00:42, 17 December 2012 (CET)

On top of that, the staging branch will never be frozen, so development will never stop,

I agree and disagree. The staging branch should be "frozen" temporarily from receiving new features and only allowing bug fixes. This is done prior to a new release. Once completed, some (or all) of what's in Master is moved into "unfrozen" staging, and that repeats the cycle, so most of the time staging (I prefer "testing") is unfrozen. There's been a lot of confusion with terminology meaning one thing here and another thing elsewhere. When I find the time, I'll try and start defining terminology on the main process page. RobT (talk) 20:57, 16 December 2012 (CET)

What I am trying to specify is a process with 2 types of releases. There would be a more up to date release, lets call them "unstable" releases, with the latest features an developments, that are made as snapshots of the staging branch every 3 monthes. The release of a new "stable" one should not stop these "unstable" releases, as we would branch staging into the 2.N+1 branch 4 monthes before the next "stable" release (so this would happen only every 1 year and 8 monthes). After this branch is created, 2.N+1 receives no new features, but the staging branch can still receive for the "unstable" release. By having it this way, the "unstable" releases would not have the instability that the master (development) branch has, they would be based on a branch that has fewer (or no) breaking changes, being focused only on stabilizing the features added in master. RenatoUtsch (talk) 00:42, 17 December 2012 (CET)

I guess we are talking about Release Schedule here. That part seems to me like totally over engineered, most likely will never be applied in practice, and it isn't even clear what is the benefit of the proposed process, except over complication and locking ourself into some predetermined scheme.--Deadalnix (talk) 08:57, 17 December 2012 (CET)

It really isn't about the overall release schedule, as that would be under a 'Release Schedule' topic. Unfortunately what it is about isn't being discussed. I'm still wondering if you are going to provide any constructive feedback, what do you want to see!--He the great (talk) 05:38, 19 December 2012 (CET)

The release process explained elsewhere the page use a 3 version number system, and some branches that are defined. My proposal would be to have 2 supported version, 2.N and 2.N+1 . Nothing prevent someone from patching a lower version, but that isn't supported. Revision are published when it make sense, I don't see any reason to have a very precise schedule on this. A release is done when a critical bug is solved, or when the amount of bugs fixed justify a new release. New version are released when it make sense according to the new feature developed. As a new version here means branch 2.N+2 to maintain, it should be avoided to release too much of them (or the mechanical effect is either more version to maintain or versions maintained for a shorter period of time). The smart choice IMO here is to not release feature too often. This have the second advantage to allow for testing how feature integrate with each others before actually releasing them. I suggest we drop the word stable and the word LTS as they means different things to different person. Back on LTS, I think this is bad idea (my understanding is that 2.N is supported longer than 2.N+1 if 2.N is LTS). This will cause more painful migration to newer versions as the intermediate version may be gone or outdated when one want to do so.--Deadalnix (talk) 09:20, 19 December 2012 (CET)

The Path of Least Resistance: Incentives and Barriers

The path of least resistance is a concept I think should not be overlooked and deserves special attention, and to that end here's a section devoted to the subject.

Here is a quote from a post made by Brad Roberts that I think applies to this section:

Hoping that people fix regressions on release critical bugs isn't sufficient. Incentive and steering is required.

The full post and some discussion based on it is in here http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com?page=7

I'll describe things in another way: The path of least resistance should be aligned with the path taken when following the process, and we should remove or lessen all barriers that make following the process more difficult than is absolutely necessary.

As an example, let's say that we move to a stage where the "staging branch" is frozen from having new features merged into it because we've decided it was time to move towards a new stable release. The questions to ask (relating to this subject), are:

1) What incentives are there in place to encourage developers to focus on doing all the things necessary to get from staging to stable in a timely manner?

2) What barriers are in place that discourage developers from focusing on doing all the things necessary to get from staging to stable in a timely manner?

Example for 1) we could also freeze the Master Dev branch (for a short time) to alert and enourage developers to focus their attention and efforts on the staging branch.

Example for 2) We should try and make it as easy as possible to know what bugs exist specifically for the staging branch and list them in order of priority. If the devs cannot easily determine what bugs apply to staging, then these bugs will simply not get fixed.

My suggestion for each step in the process, is to specifically consider the incentives and barriers that will be put in place (naturally or artificially) that either encourage or discourage devs from following through with the process in a timely manner.

I would even go as far as to place a sub-section for each step in the process description, where the incentives and barriers are listed so that we can all be made aware of what they are.

Please post your comments, ideas and suggestions!

--RobT (talk) 01:00, 16 December 2012 (CET)

Indeed, raising the bar for includion to master during the final sprint seems like a good idea to me.--Deadalnix (talk) 23:16, 16 December 2012 (CET)

This is a good idea. The purpose and expectations of each step in the process should be made explicit, so that everyone is on the same page about what is supposed to take place. Of course, in practice it will probably not be 100% conformant, but at least we should put down the ideal scenario "on paper" so that we have guidelines to follow instead of everyone just doing whatever he thinks is right.—Quickfur (talk) 03:02, 17 December 2012 (CET)

Terminology

We have a problem with terminology, where certain words mean one thing to Person A and another to Person B, and yet another depending on the context.

When I find the time, I'll add a section for terminology definitions on the main page. If anyone has more time availble that I do, feel free to add such a section, and also post any terminology here that you think is in need of a clear definition for consideration. Thanks! RobT (talk) 21:00, 16 December 2012 (CET)

Seems to me that the terms currently in issue (staging) is already defined on the page. And from that definition it can't be unfrozen. I only see it useful for monthly releases as I didn't really consider creating a branch per release. LTS (or whatever we end up calling it) the staging phase can just be done in what will be the release branch.