New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] adding release process document #168

Merged
merged 3 commits into from Jun 26, 2013

Conversation

Projects
None yet
4 participants
@dbu
Member

dbu commented Jun 24, 2013

built from @lsmith77 notes from the hackday and heavily inspired by the core symfony doc. not all of the details where discussed at the hackday. i will merge later this week if we can get to agreement on the content (= the process)

New features are never added in the point releases, but only in minor releases.
With the release of 1.0, we will create a branch 1.0 to maintain such fixes,
and master becomes aliased to 1.1.x-dev.
The SE and symfony-cmf will get point releases whenever one of the included

This comment has been minimized.

@dantleech

dantleech Jun 24, 2013

Member

Should be an empty line before new paragraph I think

This comment has been minimized.

@wouterj

wouterj Jun 24, 2013

Member

yes, and I suggest to use "Standard Edition" instead of "SE" (that's just the name devs of the framework give it)

The CMF is quite new. As with Symfony 2.0, we don't want to promise BC
at all cost yet. If reasonably doable, we will keep the code BC or use
deprecations, but there might be exceptions where BC is too cumbersome.
The UPGRADE.md document will help you in those cases.

This comment has been minimized.

@dantleech

dantleech Jun 24, 2013

Member

Should we start maintaining an UPDATE.md file for each bundle too?

This comment has been minimized.

@dbu

dbu Jun 24, 2013

Member

i would only do that once 1.0 is out.

This comment has been minimized.

@wouterj

wouterj Jun 24, 2013

Member

the filename should be in a literal.

For the next releases, we will maintain BC if possible. If something needs to
be broken, the UPGRADE.md file will help you to update the project. We hope to
switch to a BC at all cost model with the CMF 1.3, which can be expected in summer

This comment has been minimized.

@dantleech

dantleech Jun 24, 2013

Member

might work better as "BC-at-all-cost model" (with hypenation) or in italics, BC at all cost

switch to a BC at all cost model with the CMF 1.3, which can be expected in summer
2014. From then on, we will work like core Symfony and avoid BC breaks at all
cost. Breaking features or fixes will then be postponed for CMF 2.0 in the interest
of a stable environment.

This comment has been minimized.

@lsmith77

lsmith77 Jun 24, 2013

Member

i am not sure about this paragraph. i see a possibility that we might even do a 2.0 next summer already. i think we will likely have a better idea once we have gotten some more feedback on the 1.0 release in the fall.

This comment has been minimized.

@dbu

dbu Jun 24, 2013

Member

should i just become very vague after line 3, something like " We hope to switch to a BC-at-all-cost model later, once the CMF has stabilized."

The six-months period is divided into two phases:
* *Development*: *Four months* to add new features and to enhance existing

This comment has been minimized.

@wouterj

wouterj Jun 24, 2013

Member

I suggest making the item 'headers' bold instead of italic

This comment has been minimized.

@dbu

dbu Jun 24, 2013

Member

this is copy-paste from symfony core. but i can change it, would make sense.

@wouterj

This comment has been minimized.

Member

wouterj commented Jun 24, 2013

What about security maintenance?

@dbu

This comment has been minimized.

Member

dbu commented Jun 24, 2013

this is a community effort - i don't think we should/can promise anything here. we could mention security in the "Maintenance" section to make that more clear.

@dbu

This comment has been minimized.

Member

dbu commented Jun 24, 2013

okay, updated. better like this? anything else?

@lsmith77

This comment has been minimized.

Member

lsmith77 commented Jun 24, 2013

I think we need to explain a bit more the versioning of the CMF as a whole vs. versioning of individual components and bundles (see the routing stuff). ie. mention that we allow minor version updates between CMF milestones.

**symfony-cmf Standard Edition**. The individual CMF bundles and components may
release minor versions more often, if needed. ``symfony-cmf/symfony-cmf`` will
always point to a working combination and only integrate newer minor versions
when a minor release of the CMF is scheduled.

This comment has been minimized.

@dbu

dbu Jun 25, 2013

Member

@lsmith77 this section explains about the release of the complete cmf versus individual bundles/components. if you have suggestions how to improve the section, they are very welcome, it is indeed not as clear as i would want it to be.

This comment has been minimized.

@lsmith77

lsmith77 Jun 25, 2013

Member

ah sorry .. must have overlooked this one .. looks good to me!

dbu added a commit that referenced this pull request Jun 26, 2013

Merge pull request #168 from symfony-cmf/release-process
[RFC] adding release process document

@dbu dbu merged commit 77bb5f8 into master Jun 26, 2013

@dbu dbu deleted the release-process branch Jun 26, 2013

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