Tags:
create new tag
, view all tags

Get extensions from the trunk

Currently when we build a release, the release is built using sources that are branched from trunk. This is to provide greater stability on the patch branch while allowing the trunk to move ahead. This approach means that if any bugfixes are checked into the core, they must also be merged to the patch branch - which is fine.

What is not so fine is the fact that the same is currently true for the default extensions. The extensions on the release branch are identical to those on the trunk. If they are not, it indicates a major problem. So why do we need to take the risk of maintaining two sets of sources for them? In the past we had to because of the way the build system would pick up sources from the twikiplugins dir, but we have fixed that.

All extensions are "released" in two ways; by upload to TWiki.org, and by inclusion in the standard release package. IMHO when a release is built, it should be built using the latest extensions on the trunk - i.e. those that have been uploaded to TWiki.org - and not some dubious sources that may or may not have been correctly synched with trunk. If an extension is branched for any reason (god forbid) then the sources from that branch should be used, but I suspect this is a highly unlikely scenario.

So I'm proposing the following process change: Build releases using the extensions from the trunk - i.e. those uploaded to TWiki.org Plugins web. Forget about branching extensions. The benefits are:

  1. lower risk, as only one set of sources need to be maintained,
  2. less risk of extensions getting out of step with TWiki.org,
  3. less effort required to check into a trunk only,
  4. Bugs don't get left in risky transition states while they wait for merges.

-- CrawfordCurrie - 20 Mar 2008

I dissagree. When a release package is built, we need to be able to specify exactly what changes go into the extensions, in the same way as we do for the core. Extensions are expected to move quickly, and with the long release cycles, do eventually change in a way that is risky to add to a Patch release.

If for example, we find a serious issue in 4.1.2, that causes us to need to release a patch, we should not be forcing all our users to go through the potentials of a plugin suite upgrade - including the most painful bit (if they customised it) - PatternSkin.

So from a release, configuration management and qualifications point of view, your proposal would increase the risk to users.

-- SvenDowideit - 20 Mar 2008

Could you please create a change request so that we can track this proposal with the 14 day review period?

-- PeterThoeny - 21 Mar 2008

Sven, good point about PatternSkin. That really is a killer. When I sit down and think about it, my issue is really with the pain associated with checking the same code into two places. That can be moderated by a couple of simple tools:

  1. merge.pl n - merge change n into the branch under pwd (attached to this topic)
  2. diffs.pl n - show differences between the subtree under pwd and the branch that was the target of checkin n
And, of course, the difficult part - the doc to be able to use them.

-- CrawfordCurrie - 21 Mar 2008

I understand the issue

Because our 4.2.0 release took an unusual time from feature and code freeze till release (more than 6 months instead of the usual 3-5 weeks) we have had to double check-in for an extended period.

In reality the two sets of default extensions have been identical for 6 months. And it has been a pain to keep them in sync and I have personally had to do a raw file copy to get keep them in sync and I even screwed it up once - which I caught when I saw the checkin email.

The situation now is that we will move towards a 5.0.0 while having a parallel 4.2.X branch. I expect to see 4.2.1 release very soon (weeks) and maybe a 4.2.2 in 1-2 months after. And then I expect patch releases only when needed for security reasons.

It has been the rule that plugins should always be released from trunk (MAIN in the old days) except the default plugins that must be released from the current release branch.

This makes sense because why share a plugin version on t.o. which does not run on the current TWiki but will run on some unreleased development code?

On the other hand. Why change a plugin so it will not run on the previous version of TWiki? It would encourage making changes to plugin compatible if the release branch uses the trunk plugins.

Then there are the exceptions. If a release of TWiki gets a new feature then naturally it has impact on the default skins Pattern and Classic.

So maybe the best solution is a little bit of both.

Maybe we should change the build script for 4.2.X to use extensions from trunk except the skins?

More exceptions could be made if other default extensions need to be developed as part of 5.0. Until now this has not really been the case in the past.

Problems with exceptions is for all members of the community to keep a synchronized view on the list of extensions that need to be kept in sync.

As you see from my statements I am not sure myself what is the best approach and look forward to hear more arguments and ideas.

PS: 14-day rule does not apply until CommittedDeveloper and DateOfCommitment are added to the form.

-- KennethLavrsen - 21 Mar 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt merge.pl.txt r1 manage 1.0 K 2008-03-21 - 07:49 CrawfordCurrie  
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2008-03-21 - KennethLavrsen
 
  • 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.