Matt, I think most of your points are valid from the perspective of a Symfony user. They might be less valid with the POV of a core dev. Let me give you an example to illustrate the difference: - A user would prefer not to have BC breaks to avoid having to upgrade his application, - A core dev would sometimes love to break BC in order to remove limitations of the current API. My experience with low level SW development is that you can not come with a solid and future proof API if you don't think well in advance and have some time to polish things.
On Wednesday, January 16, 2013 2:05:26 PM UTC+1, Matt Robinson wrote: > > On 16 Jan 2013, at 12:05, Victor Berchet <vic...@suumit.com <javascript:>> > 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. The problem here is that there will be a lot of BC break from day 1 of the 2.3 dev cycle, which almost nobody will have tested. 3 months seem a little short to me to stabilize everything (including the dev phase). Of course I also hope it will be enough. > > > 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. I think we agree here: The sooner 2.3 out, the better but we should not sacrifice stability as 2.3 will freeze the API for a long time. With the amount of changes already planned for 2.3 I fear that the cycle will be too short and I might be wrong. However if we should delay 2.3, the sooner the better. > > > 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. > > Look at the Form component for example (there are also other examples). The component has some issue as of today, do you have any idea what feature are stable, what feature are less stable and what feature will be subject to change in the coming releases ? Quality is also about measuring things. > 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. It's exellent for users. Developers would like to have some idea of what's coming in advance (see the introduction of my email). > > 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? > > The red tape will probably be used much more after 2.3. I think that planning for the next release is enough - please note that it implies some planning for further release: I gave the example of the CSSSelector component that has some known issues. It is probably note in priority list for 2.3 (even more if the cycle is 3 month long) which means that it will be pushed to some further release. -- -- 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
