That's very good. +1
2012/2/23 Malin Nicolas <malin.nico...@librenberry.net> > it's a clear vision for end user :) > > +1 > > Nicolas > > > Le 21/02/2012 10:18, Jacopo Cappellato a écrit : > >> Hi all, >> >> >> I would like to share some ideas I have to make our release plan more >> clearer, public and well defined. >> >> This plan doesn't require additional work from the community (apart from >> the due diligence when we will call for votes) because I will take care >> about preparing release candidate files, sign them and call for votes; then >> publish them if the vote is successful. >> This is basically what we did in the last 2 years with the only (big) >> difference that the release schedule will be decided and announced in >> advance on fixed dates. >> For example, we could decide that during the year 2012 (the same scheme >> could be used for 2013 etc...) we will issue a release from each branch >> every 4 months like this: >> >> * release 11.04 around 2012-04-15 >> * release 11.04.01 around 2012-08-15 >> * release 11.04.02 around 2012-12-15 >> >> * release 10.04.01 around 2012-03-15 >> * release 10.04.02 around 2012-07-15 >> * release 10.04.03 around 2012-11-15 >> >> * release 09.04.02 around 2012-02-15 >> * release 09.04.03 around 2012-06-15 >> * release 09.04.04 around 2012-10-15 >> >> Or we could decide on a less aggressive schedule and release each branch >> every 6 months etc... >> >> And we could also vote in advance for the time a release branch will be >> closed: for example we could vote that the community will not release and >> apply patches to the release branch 09.04 after the release 09.04.04 (this >> is just an example as I would like to propose to close the 09.04 branch >> earlier than this). New patches/contributions (always welcome) for that >> branch (after it is closed) will not be applied to the branch and will stay >> in Jira for interested parties (unless the community will decide to reopen >> it). >> >> In this way users will know in advance when a branch will be deprecated, >> how many bug fix releases will be issued and based on this information >> could prepare in time for the upgrades (or switch between major releases). >> >> Of course there will be exceptions: maybe we will have to release out of >> schedule to fix some major security issues or we could skip a release if no >> changes since the previous one were committed etc... >> >> When the plan is in place we could then prepare a nice roadmap diagram to >> be published in our Download page. The roadmap will not be feature based >> and for this reason it should be doable with the current structure and >> resources we have in the community: I know it would be also nice to plan >> and work together on a features set, but this will definitely require more >> coordination, agreement and effort... we can (and should) always try to do >> that also but this is another topic (for another thread). >> In the meantime, with this time based release plan we will have something >> real to play with. >> >> Please let me know what you think. >> >> Thanks, >> >> Jacopo >> > > -- I am hongs
