Hi list, It just occurred to me that it would be a good thing to try out a new release policy. Since a while, we have this awfully long major release cycle, together with a more frequent minor release cycle on the -stable branch. This is how it is, we already tried to make major releases more frequent but apparently this goes against the natural pace of the project, so this message won't be a plea for changing this. Quite the contrary, I think that a somewhat long release cycle has also its advantages, as it gives time to the plugin ecosystem to mature around new versions and also gives us enough room to polish the features or the API we want to maintain in the long term. But of course the disadvantage is that a lot of the good work that appears on trunk takes a very long time to reach the users, at least the vast majority not comfortable with the idea of using the latest commit on trunk of the day. Making the new cool features also available on -stable would somehow defeat the very idea of having a -stable branch. It would put too much at risk the API stability we try to guarantee to plugin authors, as big new features often come together with API clean-ups and evolution.
So how to preserve the advantages of this model while at the same time making the new features more readily available to a greater number of users? Simple. Make some "checkpoints" on trunk. Long time readers of this list already now about that old idea of mine of making "pre"- releases. Those would be well tested, stable versions which we are confident people could use (no big deal, that's how we already feel about trunk, at least most of the time, so this would just help other people "identify" such times!). What's the difference then we a real release or even a beta release? A non-binding feature set and API. We won't make the guarantee that what's in a pre-release will be the same in the final release, we reserve the right to change our mind. Of course, from pre-release to pre-release, we'll document what has changed, in order to make it easier for plugin authors who which to support these pre-releases. I believe this is worth trying, now. I'm all for making a 0.13pre1 release by the end of this month (knowing we're not yet done with 0.13 even for a beta, but it's nevertheless already good and stable enough to start to get people using it more broadly). -- Christian -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
