Forum OpenACS Q&A: Meaning of oacs-4-6

Posted by Tilmann Singer on 03/06/03 10:03 AM

I just 'cvs update'd a checkout of openacs with the sticky tag oacs-4-6 that was last updated a few weeks ago and found it in a broken state (see this thread: https://openacs.org/forums/message-view?message_id=83845 )

Until now I had the assumption that keeping a cvs checkout of oacs-4-6, doing cvs updates of it and running the occasional update scripts in the apm would ensure having a stable OpenACS system with the latest bugfixes included, as opposed to running from one of the tarballs which makes it impossible to easily get new bugfixes.

This convenience of having a cvs tag that marks a stable release is lost when everybody commits new stuff to oacs-4-6. Shouldn't we rather concentrate on committing new stuff to HEAD, and backporting it when it's desired and proven to be mature?

I know a feature freeze is hard and the desire to get new stuff in is big - but even bigger is the need for a stable version, IMHO.

2: Re: Meaning of oacs-4-6 (response to 1)

Posted by Jeff Davis on 03/06/03 10:18 AM

Tilman, Lars and don both committed a bunch of stuff yesterday and I am not surprised there are a few problems. I don't think it's realistic to think the HEAD or the HEAD of a branch will always work. HEAD of anything is definitely not a "stable version". We do have a tag on 4.6 for the latest work excluding their commits which is oacs-4-6-1-b2 but it is a symbolic tag rather than a branch.

If I were you I would revert to that tag and wait until those problems have been fixed.

Also regarding working on head v. on 4.6 I think it is a *lot* easier to merge from 4.6 to HEAD than the other way around so for most things it would be better to do the work on 4.6 and merge forward.

3: Re: Meaning of oacs-4-6 (response to 2)

Posted by Jeff Davis on 03/06/03 11:36 AM

We had an exchange on irc about this.

The bit I think deserves more discussion is:

I think it's pretty important to think about the implied contract for people using checkouts and I think the disadvantages of try to insure the HEAD of a branch under relatively active development is stable is something we can't do. We should probably formalize it and post it somewhere. I think it would go something like: "HEAD: no gaurantees at all that it will install work or be upgradable, oacs-4-6: best efforts at installability, no upgradability gaurantee, beta tags: gauranteed installability no gaurantee of upgradability, release: gauranteed installability/upgradability.

Although hopefully the discussion won't be about my utter inability to spell either upgradeability or guarantee. At least I am consistently wrong.

4: Re: Meaning of oacs-4-6 (response to 1)

Posted by Don Baccus on 03/06/03 06:23 PM

I think we're committed to solving problems on the oacs-4-6 branch ASAP, but as Jeff notes can't guarantee that we don't mess up. I did full testing of the PG version after making my rather massive changes but didn't realize I'd accidently walked over three or four oracle XQL files as well.

I'd love to keep our minor number upgrades really minor in the future - when things stabilize more. Right now we're making such great progress that being more agressive on the oacs-4-6 branch makes sense and, as Jeff says, merging forward from there's a lot easier than vice-versa (all those localization changes on the HEAD would make it very laborious to pick out the proper changes)

As things get more stable and as we get better at pushing out maintenance releases in a timely fashion hopefully the need to pull CVS copies in order to keep abreast of major bug fixes will be reduced.

Remember the PostgreSQL history ...

OpenACS 3.x, when first released, *required* PG 6.5 Beta, it simply wouldn't run on the PG 6.4 production release.

For a couple of OpenACS 3.x releases after the very first one, we required either Beta or the very latest production release of PG due to the pace at which they fixed bugs that we kept stumbling over.

Now, for some time, we've been able to work with at least one version older than the current. That's because their project's matured to the point where the current version no longer feels so seriously broken that one can't wait until the next version to come out.

Of course I'm ignoring the mini-fiasco in PG 7.3 with default timestamp semantics changing from with to without timezone but in general we've been able to work with PG 7.N.x and PG 7.N-1.x (where N is the major release).

Hopefully after we swallow the elephant known as OpenACS 4.7 (an elephant due to all the localization work) our stuff will mature, too ...

5: use cvs tag oacs-4-6-1-b2 (response to 1)

Posted by Andrew Piskorski on 03/07/03 07:51 AM

Tilmann, I think your problem is that you used the 4.6 branch the wrong way, or at at least thought about the wrong way. The "oacs-4-6" tag is the branch tag, so if you cvs update to that, you're saying, "Give me the very latest development on the 4.6 branch, the stuff which will eventually become a 4.6 point release." This is presumably more stable than cvs HEAD, but there is absolutely no guarantee of that. And you could always be really unlucky and get the first half of a developer's two cvs commits which need to go together.

If you want stability, you need to use a specific release, like 4.6, 4.6.1, 4.6.1 beta1, 4.6.2, etc. The "oacs-4-6" cvs tag is not a specific release. The cvs tags "oacs-4-6-final", "oacs-4-6-1-b1", and "oacs-4-6-1-b2" are.

Of course, it's quite true that there might be a very bad bug in, say, "oacs-4-6-1-b2", which someone has fixed on the "oacs-4-6" branch but not yet tagged for release. And in that case, the tip of the branch will in one sense, coincidentally, be more "stable" than the last tagged release - it will work better. But that's an accident, and far from guaranteed. By design and common sense, any released version should be more "stable" than source code that's a moving target. And the tip of any branch, be it the head or the 4.6 branch, is always a moving target. The only difference between head and oacs-4-6, is that oacs-4-6 is probably a much slower moving target than the head.

6: Re: use cvs tag oacs-4-6-1-b2 (response to 5)

Posted by Tilmann Singer on 03/09/03 11:57 AM

Thanks for all the clarifications! I will only cvs update to release tags from now on when stability is most important.

7: Re: Meaning of oacs-4-6 (response to 1)

Posted by Tom Mizukami on 03/10/03 05:21 AM

I'm a complete CVS newbie - so forgive me if my question is stupid. Can CVS be set up so all development work is done on a branch and the trunk is maintained as the latest stable release plus bug fixes? I think may of us in an open source community would try to do what Tilman did; set up a system to make it easy to grab the latest release plus bug fixes.

8: Re: Meaning of oacs-4-6 (response to 7)

Posted by Andrew Piskorski on 03/19/03 12:15 PM

Tom, yes using CVS in that fashion is probably possible, but it's not how it's typically used, and I don't see any advantage to that scheme either. It doesn't really solve any problems.

People who aren't familiar with CVS, well, generally they don't use it. They download a tarball instead. So I think perhaps what you should really asking for, is more rapid release of point releases, with tarballs, plus also some clear instructions on the website for how to properly yank different releases out of cvs, since some people definitely will want to do that.

(Personally, I never use source tarballs when I can pull a release from CVS instead. CVS is just better.)