On 16 Jan 2013, at 12:05, Victor Berchet <vic...@suumit.com> wrote: > - We don't start with a plan. It means that our development does not really > begin at the start of release cycle but can span over multiple release cycles > - you can see this by looking at the amount of PRs that are already pending > for 2.3,
I'd call that a feature, not a bug. :) > - We don't have a longer stabilization phase for LTS releases. I'm sure we'll find out soon enough if this is necessary. If it turns out we need more time, then surely Fabien will announce that the stabilisation phase for the LTS will be extended. It seems far too soon to say, though. As you point out above, while many are busy stabilising the upcoming release, others will be busy working on features for the next release, so the 1 month development is more like 2+, and the development's more like testing and integration at this point, if PRs are already lined up to go into 2.3. > One thing we could do is to release 2.2 as planned at the end of February and > delay 2.3 LTS until November - that would be a 8 month development phase and > a 3 month stabilization. Could we really ask third-party bundles to upgrade > to 2.2 in January and February, introduce new BC breaks for 1 month (some of > the BC breaks will be deprecations in 2.2, some other will be introduced at > the start of the 2.3 development phase) and upgrade again to 2.3 during April > & May ? I agree that this can be annoying, although I wouldn't say it's a problem with the release process, and it's one that should go away after 2.3. I think delaying the LTS release until November is a potentially bigger problem - Symfony will have been without a supported LTS release for a whole year by then. I think it's been made fairly clear across the community that sf 2.1 and 2.2 are sort of interim releases, so potentially breaking BC for developers twice (at scheduled times!) in 6 months with the promise of stability in May is totally acceptable to me (and I suspect most others). Of course we should be making sure that we leave enough time that we don't screw up, and I'm sure that's your point too, but we need to balance that against delaying the promise of stability. The sooner 2.3 is out, the better, I think. Pushing release back to November without good evidence that it's necessary would be a mistake too. > One other major topic I am not happy with the the predictability of the > releases - in term of content & quality. … huh? I don't get what you mean about quality. In terms of the content of releases, I sort of see your point. I think that simply having a roadmap of any large planned features should be more than enough to reassure folks though. And I'm not convinced that it's necessary. The regular communication of new features on the blog has been excellent so far, I think. Personally I'm much more worried that we'd be adding pointless red tape and barriers to the inclusion of new code in releases simply for the sake of … I'm not sure what. Why would it matter that you can't predict what the new features will be more than 1 release in advance, as long as the framework maintains BC? Or do you mean that you might not be able to tell which release a new feature (that you already know about) might be released in? -- Matt Robinson https://lazycat.org/ -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
