Hello Odd Simon, (first let me make a note about the terminology I'll use below: I'll refer to 0.11, 0.12 as being "major" versions and "0.11.1", "0.12.1" as "minor" ones)
osimons wrote: > On May 2, 11:04 am, Christian Boos <[EMAIL PROTECTED]> wrote: > >> Well, from the lesson learnt during 0.10-stable maintenance, I can say >> that using svnmerge for tracking to merges from trunk to stable quickly >> becomes unusable, as there's too much manual maintenance to do for the >> "blocked" changes and the situation, while manageable at the beginning, >> only worsen over time, as more and more changes need to be blocked. >> >> However, it could eventually work if the merges are done in the other >> direction (from stable to trunk), as bug fixes should usually also apply >> to trunk. For example, this is what the Mercurial project does, they >> have an hg-stable branch where they do the bug fixes, and that branch >> regularly gets merged into the default branch (the development branch >> for the next version). This minimizes the merge tracking maintenance. >> >> > > I like that idea. It would make for fewer changes to sync, and as the > differences between branch and trunk increases over time it becomes > more likely that a merge could break something unexpected. Better it > breaks in trunk than in the stable branch. > > That then means we need to make the 'backport' decision at commit > time, and commit to branch or trunk as appropriate. A periodic sync > should then be OK. > Yes, this is mostly deciding whether it's a bug fix as opposed to an enhancement. Also, a bug that needs an API or a behavior change in order to be fixed should not be targeted for 0.11-stable. > Which again raises a new question of all the changes scheduled for > 0.11.x, and the development policy that has so often been discussed: > Only major bug and security features for stable brances, and new > development happens in trunk for next major version. Yeah, I think those are good guidelines, except for the "major" qualifier: I see no reason that fixes for regressions, for minor bugs or even trivial fixes shouldn't go in as well. Anything non-obvious could of course benefit from some review, either here on Trac-dev or on tickets. This is for 0.11.1 of course, the more the minor version number increases, the more serious the bug should be. For example, 0.10.5dev had very few "minor fixes". > Based on this > policy only be a few handfuls of the current 177 open tickets for 0.11- > stable should actually go in the branch, the rest should be targeted > for 0.12 in trunk. > A handful for 0.11, yes, but I think that for 0.11.1, a good deal of the 116 opened defects are worth addressing (e.g. I would consider fixing something like 40 tickets fixed for 0.11.1 to be a good achievement). There's a lot of triaging work that has to be done though (*), as: - all 0.10.5 tickets should be moved forward (0.11.1 or later) - some 0.11.1 defects and untriaged tickets are likely "worksforme" - some 0.11.1 defects are actually enhancement requests and should be moved to 0.12 or beyond > An 0.12 release that should not be in the far too distant future, > btw... :-) That would have been the topic of another mail (and there will certainly be more detailed ones to come), but now while we are at it... I see two main directions for improving our development process for 0.12: - don't be hesitant to make pre-release versions, clearly labeled as such (0.12pre1 or 0.12alpha1), as soon as we feel we're having an interesting enough new feature set to propose to our users - instead of having only vague 0.12, 0.13 ... 1.0 milestones, also use topic milestones (e.g. a wikidom milestone, for all tickets related to the wiki refactoring) and use them to track progress on topic branches. Once the branch is going to trunk, the topic milestone can be deleted and the tickets retargeted to the corresponding milestone (0.12, 0.13, whatever is current at the time the branch is merged). This is clearly more telling than assigning something to 0.13 or 1.0: when it makes sense, a bug or enhancement is assigned to a topic and when that topic is ready it goes to a given version Of course the two ideas are complementary: once we close one or two topic branches, we can decide whether it would be adequate to create a new pre-release. I see only advantages in making pre-releases, let me discuss some of them in more details. 1) Reference points during the 0.Xdev period We already created a 0.12dev version on t.e.o instead of the too broad "devel" that was used in the past. Nevertheless, we're still going to have to ask about the actual trunk revision people used. Also, we have a track record of having a very stable trunk. I see no reason to change that, we should strive at making non-disrupting changes on trunk, so that people who want to stay on the edge can continue to do so. Or they could reduce the risks of accidentally updating to a bad changeset by only updating from one pre-releases to the next. Such pre-releases could be preceded by a mini-freeze period of a few days where everyone test the current status in order to make sure we have a reasonably stable intermediate version. 2) Better visibility for the API changes During 0.11dev, the API was unstable and people were reluctant to adapt their plugins because they had to follow a constantly moving target. But having the freedom to introduce new APIs and make them evolve during some time is precisely the purpose of a development period! If we have intermediate versions, it gives the plugin developer an reference point against which she can develop her plugin (as by definition of a released version the API won't change). Moreover, it gives us the possibility to document all the API changes between those intermediate releases. That will help us to create the "final" API change document, the one detailing the changes between major versions. The plugin developer has everything to gain from this approach as well: instead of wasting time adapting his "trunk" compatible plugin against an API which has not yet stabilized, he can wait for the next intermediate release, and get a summary of the changes he has to take into account. Not to mention we increase the chances to get feedback on the new or modified APIs before they are actually frozen, which is what will happen if plugin developers only start to adapt or create their plugin once the major version is released. To sum up, I'd like to propose the following API changes guidelines, taking 0.12dev, 0.11-stable as examples. a. APIs from 0.11 should not change in 0.11-stable b. non-deprecated APIs from 0.11 have to be supported throughout 0.12dev (and beyond in 0.12-stable due to a.) c. APIs deprecated in 0.11 can be dropped in 0.12dev (preferably not at the very beginning of the development cycle, to ease transition) d. new APIs can be introduced anytime in 0.12dev, preferably after some review. However a note about the change should be added in a CHANGES file. The status of the CHANGES will be frozen after each intermediate release, so that one can quickly see what has changed since the last intermediate release Let me take an example to illustrate point d. - r7290 introduces a "IFooBarListener", CHANGES looks like this: ---- Trac 0.12dev - interim release 'FooBar' (--, 2008) * introduce IFooBarListener so that components can listen to various noises ---- - r7321 changes the spelling to IFoobarListener ---- Trac 0.12dev - interim release 'foobar' (--, 2008) * introduce IFoobarListener so that components can listen to various noises ---- (no need to talk about the former transient spelling, we're "in flux") - r7333 - time to release foobar, ---- Trac 0.12pre1 - interim release 'foobar' (May 30, 2008) * introduce IFoobarListener so that components can listen to various noises ---- Then we realize we forgot to add methods into this interface! Damn... - r7334 adds some methods to this interface ---- Trac 0.12dev - interim release '???' (--, 2008) * added method foo_bar_triggered to IFooBarListener Trac 0.12pre1 - interim release 'foobar' (May 30, 2008) * introduce IFoobarListener so that components can listen to various noises ---- See? Now if a plugin developer implemented IFoobarListener, he can quickly find what he needs to do in order to adapt its plugin once the next interim version is out. When we write the final TracDev/ApiChange/0.12 document (mirrored in CHANGES-0.12 ?), we will have all the information we need at hand. Of course, there we sum up all the changes, so that the line about IFoobarListener will read something like: IFoobarListener interface added (contains one method for being notified about xyz) - or more likely in this specific case, will contain nothing at all as we discovered we didn't need that interface... I believe that if we're adopting this new practices, we will have a much better chance to have faster release cycles: after a while, we will just have to decide that, ok, that last 0.12preN release was actually pretty good, so let's stop here and make that 0.12, going forward on 0.13 (or 1.0 or whatever). Now, if we can keep the current development pace, it's not impossible that the first 0.12pre1 with i18n support will be out even before 0.11 proper :-) -- Christian (*) I noticed that sid is back, so there's some hope about the triaging ;-) Thanks a lot for your work sid, it's highly appreciated! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
