create new tag
, view all tags
NOTE: This topic is obsolete. Please jump to SubversionReadme for the current Subversion process for TWiki!

One SVN Branch per Release

A new branch model with MAIN branch and DEVELOP branch was introduced at the time of working on the DakarRelease. The intent was to incrementally merge DEVELOP changes back into MAIN. This model does not really work well for various reasons, one is my lack of time commitment.

Here is a simple solution that we can attack after the DakarRelease: One branch per production release:

At the time of a code freeze, a new branch is created. It needs to be defined who is responsible to merge the branches between code freeze and release.

This topic originated in an IM conversation between CrawfordCurrie and PeterThoeny.

Open for discussion. (Once in good shape, this topic should be changed to mixed DocumentMode on top, followed by ThreadMode discussion section)

-- PeterThoeny - 04 Jan 2006

Actually it originated much earlier than that, back when we first spawned DEVELOP branch, but who's counting.

Another advantage of this approach is that there is a natural relationship with a docs web of the same name on TWiki.org, which would allow docs to be worked on in TWiki (which Peter is really keen on) and automatically merged to the relevant branch in subversion.

-- CrawfordCurrie - 04 Jan 2006

The docs web is another question discussed in DakarDocumentationModelIsBroken. To avoid confusion, we definitely need to keep one and the same web for doc authoring, the TWiki web. That web needs to be kept in sync with whatever release is work in progress.

-- PeterThoeny - 04 Jan 2006

many people do not agree that having one Documentation web that attempts to keep in sync with work inprogress, while also appearing to non-developers as being for the last full release is avoiding confusion. This is why most agree that we should have one Documentation web per release. This is also why we put that documentation into svn - then it matches, and is trackable using the same tools as the source.

-- SvenDowideit - 04 Jan 2006

Take the example of a security alert where you need to re-release two different releases. You also have to update the same topics in both those releases but the topics have changed between the releases and both sets of topics are correct as they are for their release, barring additional security warnings.

How can we manage that without having separate locations where we can work on both sets of documentation?

-- SamHasler - 04 Jan 2006

The branch question and doc location question are two subjects. Please carry on the doc location question in DakarDocumentationModelIsBroken.

-- PeterThoeny - 05 Jan 2006

I don't think you can separate the two questions that easily; the working model for docs has to be intimately tied to that of code. The risk of getting out of step is far too big otherwise. So you have to consider both questions at once.

I'd be surprised if there were any negative inputs to the branch-per-release idea. AFAICT it's no brainer; we should "just do it".

-- CrawfordCurrie - 05 Jan 2006

I agree, it is a no brainer. Who is taking the branch merger role in the phase between code freeze and release?

-- PeterThoeny - 05 Jan 2006

One word of caution. Creation and innovation is fun. Testing and bug fixing and especially documentation is less fun. That is how we humans are. That cannot be changed.

So I want to advice caution about the TIMING when to branch the next release. All projects (professionel as well as open source) have too few resources. TWiki is no exception. Very few people do a great job - also with the boring tasks. And they need all the help they can get.

At the release meeting we discussed the release schedule and frequency. We has concensus that we needed rare major platform type releases and more maintenance releases (bug fixes and small enhancements) that can be patched or easily installed on top of a running production server.

We agreed that Dakar was close to ready for release and we cannot be far now. The current phase is the most boring but also the most necessary to get a quality product out of the door.

So my proposal is

  • Do not branch off Edinburgh (equal to open the door for people to address new features) until Dakar is released. Doing it already when you have code freeze is too early and moves focus and the less committed developers away from the duty tasks and on to the fun tasks.
  • Make sure there is at least one committed maintenance release targeted max 2 months after the release. Beta testers reporting bugs have been few. Once released we will see an increase in bug reports from new people we have not heard from yet.
  • Make sure that after Dakar is released, bugs found on Edinburg development are merged back to Dakar when possible and released with Dakar maintenance updates.
  • Make sure the bugs fixes to Dakar and the patches are available for those that needs them urgently. I.e. it must be possible to search and list the fixed and non fixed bugs found AFTER the release of Dakar. That should be a simple task of doing the right TWiki topic that does the right search from develop bugs web.
  • Plugins working on Cairo but not on Dakar are many. It may be that their original authors used non API calls but to the users they have a high value and getting as many as possible updated and working will add a lot of value to the TWiki customers and will for many be the argument against upgrading. Spending energy on plugins may add more value the first months than developing Edinburgh
  • Make sure the roadmap for Edinburgh is clear. Dakar was supposed to be a performance improvement. It isn't really. Are those that want an Edinburgh branch now going to work on this? Or are they pushing to make new features?

So branch yes. No brainer. But wait spending energy on new features until Dakar is released. We are hopefully only talking days. And those that push for the branch now are those that are less willing to pull the load with the boring tasks like bug fixing, testing and documentation.

-- KennethLavrsen - 06 Jan 2006

i have spent much time the past few weeks testing and repairing and upgrading plugins so that they do work with dakar (for an up-to-date status, see http://svn.twiki.org/svn/twiki/branches/DEVELOP/twikiplugins/TWikiInstallerContrib/lib/TWiki/Contrib/TWikiInstallerContrib/plugins.NOTES) --- perhaps the list is smaller than you think? i will be emailing plugin authors tomorrow to see if i can enlist more help (or at least find out the status of those people and plugins).

i've created a personal scratch branch so that i can check in code during the code freeze.

otherwise, i agree with your analysis.

-- WillNorris - 07 Jan 2006

You truely have been making a significant contribution on the plugins and so have others. I was refering to what to prioritize AFTER the initial release Dakar. And this is where my feeling is that we can add much more immediate value by fixing some of the not yet working Plugins and Add-ons before starting focussing all attention to new Edinburgh features. (I had written "Dakar" instead of "Edinburgh" as the last word in the Plugin bullet and that made my statement a bit wrong, sorry about that - corrected now).

-- KennethLavrsen - 07 Jan 2006

Some of what Keneth says leads to the conclusion that Edenburgh should be blocked until Dakar is really, really complete. As in fully documented, fully packaged, all the issues resolved, and all the plugins that people still use in Cairo are brought forward.

I certainly can't imagine Microsoft releasing a new vesion of Windows in which Freecell and Calculator didn't work and MS-Word's export to HTML wasn't fully functional. And yes, I realise that Microsoft do officially sunset various features and packages. Perhaps we should too.

-- AntonAylward - 07 Jan 2006

OK, as we now need a branch, and quickly (for TWikiRelease04x00x01) - this is the plan for now

  1. create an svn tag from the point of release to http://svn.twiki.org/svn/twiki/tags/TWikiRelease04x00x00
  2. extract the release tgz into a checkout of that tag, and commit into it the actually released files
  3. create http://svn.twiki.org/svn/twiki/branches/TWiki04x00 from the same place
  4. then merge across all commits / Bugs listed on TWikiRelease04x00x01
  5. build and upload it as on BuildingARelease
  6. create a patch, and a zip containing only the changed files to simplify updating.

This is doccoed more formally as a set of steps on BuildingARelease

-- SvenDowideit - 07 Feb 2006

The step (4) in the process described by SvenDowideit should be a "one-shot-this-time-only" step, because the number of bugfixes commited to DEVELOP.

Now that we have a branch, fixes should go to the branch andb then integrated into DEVELOP, not the other way around.

-- RafaelAlvarez - 07 Feb 2006

Things have moved on since this topic was started; specifically, we are iterating onto a single branch model for the main development line, with scratch branches for developers wishing to explore ideas. The documentation is being reworked to reflect this, and I think it makes much of the debate here moot, so I'm removing this topic from CategoryProcess.

-- CrawfordCurrie - 22 Sep 2006

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2006-12-01 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.