added a new chapter about the Symfony release process #1758

Closed
wants to merge 1 commit into from

6 participants

@fabpot
Symfony member

No description provided.

@romainneutron romainneutron commented on an outdated diff Sep 27, 2012
contributing/code/releases.rst
+ Paid support after the three year support provided by the community can
+ also be bought from `SensioLabs`_.
+
+Schedule
+--------
+
+Below is the schedule for the first few versions that use this release model:
+
+ * *(special)* Symfony 2.2 will be released at the end of February 2013;
+
+ * *(special)* Symfony 2.3 (the first LTS) will be released at the end of Mai
+ 2013;
+
+ * Symfony 2.4 will be released at the end of November 2013;
+
+ * Symfony 2.5 will be released at the end of Mai 2014;
@romainneutron
Symfony member

typo here May

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@lsmith77

i think we should also add:

  • making a tentative plan of high profile features for every release
  • appoint one contributor to be the release manager that keeps an eye on the above list, keeping an eye on any merged features that are not stabilizing in time and who generally keeps an eye on the release schedule and communication with the entire community
  • creation of an invite only, but public list for large projects using Symfony2 components to help in coordinating releases (there should also be an invite only non public list for security topics, but this is likely beyond the scope of this document)
  • not sure if this needs to be mentioned, but maybe this document should also mention that there should be an UPGRADING guide with every release

finally i think it would be good to add an image with an example showing how f.e. the releases would look like starting 2.3 for the next 5 years to better visualize the time overlap.

@wouterj
Symfony member

It isn't only for the code, it is also for the documentation and the complete 'environment' around SF2. I think it is better to put this under 'Community' or create a new heading.

@deekayen

I see you're proposing to add predictability and doing so through a timed release, but I'd rather see predictability defined as a specified target feature list. Define a list of features and bugfixes you'd like to see in the next release. When those are done, make the release. Maybe a compromise would be to define a list of features that could take approximately 6 months to complete?

Making a release every 6 months is predictable, but then requires going back through the changelog to find what things were changed. It can leave features incomplete or left out even if they're close to completion. I'd be concerned with a 6 month schedule you'll get releases where it's hard to tell from version to version whether it's worthwhile to make the upgrade. If you define a list of features that make a release worthwhile, then you'll know as a user that each release has a feature set that's been considered carefully to be worthwhile feature set for a milestone.

@stof
Symfony member

@deekayen a target feature list does not provide any predictability as you cannot predict how much time will be needed to make the feature ready, especially for projects where people are contributing on their free time.
This is exactly the reason why it took us 1 year to release 2.1 whereas we also wanted to try making it 6 months at the time 2.0 was released (and waiting for the form changes to be ready, some features merged in August 2011 were still not shipped to the users)

@deekayen

A list does provide predictability, just a different kind. You're defining predictability as a timeframe. I'm defining predictability as a listed feature set. If there's a take-away, it's not that you should re-define predictability. If the time between releases is too far, I'd say too many features were defined in the list. That's just a lesson for defining future lists.

@lsmith77

@deekayen the issue is that we do have the resources to promise a release every 6 months .. we do not have the resources to promise any features .. let alone providing these features in a reasonable time frame .. i do agree that we should try to specify the "highlight" features we are working on .. but i dont think it makes sense to promise them .. or delay releases until they are ready.

@stof
Symfony member

@deekayen If you say "We will ship when all these features are ready", it does not give any predictability to projects relying on Symfony as they have no way to predict when this will happen.

And it is not that there were too many stuff on the list. The blocking point was the form refactoring which took longer than expected first.

@deekayen

I think you're diluting the value of a release by making them not uniform anymore. Again, yes, they'll be uniform by time frame, but they won't be uniform in release value. Some will have just a few bug fixes while others will have major feature enhancements or API changes. What you'll be breaking the predictability of evaluating the value of going through the effort of doing the upgrade between versions.

@lsmith77

well past experience tells us we have a good stream of small and big stuff coming in .. but people come and go .. and the focus of the new people is different. so i do think we can guarantee that every 6 months we have some nice new features.

@stof
Symfony member

@deekayen Starting with 2.3, the effort to upgrade should be very low as maintaining BC will become mandatory.

@catchamonkey catchamonkey and 1 other commented on an outdated diff Sep 27, 2012
contributing/code/releases.rst
+
+ * *Development*: *Four months* to add new features and to enhance existing
+ ones;
+
+ * *Stabilisation*: *Two months* to fix bugs, prepare the release, and wait
+ for the whole Symfony ecosystem (third-party libraries, bundles, and
+ projects using Symfony) to catch up.
+
+During the development phase, any new feature can be reverted if it won't be
+finished in time or if it won't be stable enough to be included in the current
+final release.
+
+Maintenance
+-----------
+
+Each Symfony version is maintained for a fix period of time, depending on the

s/fix/fixed

@fabpot
Symfony member
fabpot added a note Oct 3, 2012

fixed ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@catchamonkey catchamonkey and 1 other commented on an outdated diff Sep 27, 2012
contributing/code/releases.rst
+ projects using Symfony) to catch up.
+
+During the development phase, any new feature can be reverted if it won't be
+finished in time or if it won't be stable enough to be included in the current
+final release.
+
+Maintenance
+-----------
+
+Each Symfony version is maintained for a fix period of time, depending on the
+type of the release.
+
+Standard Releases
+~~~~~~~~~~~~~~~~~
+
+A standard release is maintained for an *eight months* period.

s/months/month

@fabpot
Symfony member
fabpot added a note Oct 3, 2012

fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@catchamonkey catchamonkey and 1 other commented on an outdated diff Sep 27, 2012
contributing/code/releases.rst
+Every two years, a new Long Term Support Release (aka LTS release) is
+published. Each LTS release is supported for a *three year* period.
+
+.. note::
+
+ Paid support after the three year support provided by the community can
+ also be bought from `SensioLabs`_.
+
+Schedule
+--------
+
+Below is the schedule for the first few versions that use this release model:
+
+ * *(special)* Symfony 2.2 will be released at the end of February 2013;
+
+ * *(special)* Symfony 2.3 (the first LTS) will be released at the end of Mai

s/Mai/May

@fabpot
Symfony member
fabpot added a note Oct 3, 2012

fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@fabpot
Symfony member

@lsmith77 I've just added an image showing the next few releases.

@fabpot
Symfony member

@WouterJ I've moved the file under the community section.

@stof
Symfony member

@fabpot the meaning of the different colors in the image is missing (it should be explained in the doc rather than the image to allow translations)

@weaverryan
Symfony member

I'm happy to proof this and merge it in (and I can also look at @stof's last comment). But, have we officially decided and agreed on this approach? I honestly don't think we'll choose a very different path, but I don't want to merge this until we're all sure.

Thanks!

@fabpot
Symfony member

@weaverryan I've talked about this approach at SymfonyLive London and San Francisco, I posted this on the dev mailing-list a long time ago, and we now have this PR waiting for comments for a very long time too. So, I think we can safely merge this and make it official. There are a couple of interesting comments made by @lsmith77 that I think need to be taken into account, but probably not in this document.

@weaverryan weaverryan added a commit that referenced this pull request Oct 8, 2012
@weaverryan weaverryan [#1758] Minor tweaks - including fixing syntax errors around the imag…
…e directive and describing the image
b4687a5
@weaverryan
Symfony member

Perfect! I've patched this into the 2.0 branch at sha: 717dfb2 with a few minor syntax tweaks.

If anyone spots any other changes, let me know or open a PR :).

Thanks everyone!

@weaverryan weaverryan closed this Oct 8, 2012
@fabpot fabpot added a commit that referenced this pull request Oct 8, 2012
@fabpot fabpot Merge branch '2.0' into 2.1
* 2.0:
  fixed some markup issues
  Tweaks per @WouterJ
  Fixed typo in documentation/overview
  Fixing typo thanks to @richardmiller
  [#1758] Minor tweaks - including fixing syntax errors around the image directive and describing the image
  added a new chapter about the Symfony release process
  Add missing words
  Try to fix a link
  Add missing apostrophe
  added missing letter
  fix minor typo
51f3862
@fabpot fabpot added a commit that referenced this pull request Oct 8, 2012
@fabpot fabpot Merge branch '2.1'
* 2.1:
  fixed some markup issues
  Tweaks per @WouterJ
  Fixed typo in documentation/overview
  Fixing typo thanks to @richardmiller
  [#1758] Minor tweaks - including fixing syntax errors around the image directive and describing the image
  added a new chapter about the Symfony release process
  Remove extra word
  Add missing words
  Try to fix a link
  Add missing apostrophe
  added missing letter
  fix minor typo
3f8ca17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment