Hi,

I forgot to pull in the 'tags' when I mirrored the SubVersion repository to Git. I would like to tag them now, but need to know what revisions was used for each tag.

Based on the following URL, is the "revision" column next to every tag the revision numbers I am looking for?

http://svn.freepascal.org/cgi-bin/viewvc.cgi/tags/?root=lazarus

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes, but beaware the some of them got merges from truk afterward.

For instance, lazarus_0_9_26_2 is based on 18716, and r18269 got merged resulting in r18898.

So you cannot simpy use r18898 for the tag.

Marc

I noticed that... Doesn't that defeat the point of tags??? Branches are used for merging things. Tags should be set in stone - a snapshot at a specific point in time. Now Lazarus developers do not distinguish between tags and branches. :-(

How long before a Lazarus tag is not merged to any more?? This strange usage of tags makes any mirroring near impossible (or a lot more work). I still think merging to a tag is wrong though. Maybe I'll just use the base revision number the tag was created on and be done with it.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/14 Graeme Geldenhuys :

After a release has been announced.

Vincent.

2009/4/14 Graeme Geldenhuys :

I guess we exploit this SVN feature to get the best out of SVN :-p

What do you suggest instead? Remove the tag and tag again? Or is deleting a directory under tags not allowed in GIT either?

Vincent

Vincent Snijders wrote

What do you suggest instead? Remove the tag and tag again? Or is deleting a directory under tags not allowed in GIT either?

Tags should be created after a release has been announced. Before that, a Branch should be used.

I have no idea if SubVersion supports deleting or moving tags. I know under Git I can delete or move tags without problems.

What worries me now with the current tags in Lazarus, is that they don't have a clean history (specific snapshot in time). You wouldn't expect to do a 'svn up' after you checked out a tag - so some users might be missing those extra commits / merges. You also can't re-tag by simply using the last merged revision, because the history is not sequential any more. I'm not sure what would happen if you created a new branch (using original revision of tag) and recreated what some of those tags do, then re-tag the branch and then delete the branch... Can you do that? The joys of tags and branches under SubVersion! :-(

In future I would recommend using branches and when a release is announced, then only create a tag.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/14 Graeme Geldenhuys :

Another school says that you need to build releases from a tagged version.

I have no idea if SubVersion supports deleting or moving tags.

Updating a directory under tags, isn't that moving tags?

Deleting the directory under tags, isn't that deleting tags?

The difference between tags and branches does only exist in the naming convention, nothing more.

Sure, I enjoy it. -)

In future I would recommend using branches and when a release is announced, then only create a tag.

Cumbersome.

Vincent

I'll second that.

Later fixes should be supplied as patches (AKA "service packs"), IMO.

DoDi

On Tue, Apr 14, 2009 at 12:33 PM, Vincent Snijders

Another school says that you need to build releases from a tagged version.

Those learners should go back to school! :-)

Now I'm starting to appreciate Linus's talk about Git at Google Talk. SubVersion really has a brain-dead design. ;-)

> In future I would recommend using branches and when a release is > announced, then only create a tag. Cumbersome.

Funny how the SubVersion documentation says that is exactly how you are supposed to use tags. If you start committing to a "tag", it is NOT a snapshot in time any more and is now considered a branch. I have been working on many SubVersion repositories from various projects. Everybody "gets" that concept, but the Lazarus developers don't.

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html

<quote>
Another common version control concept is a tag. A tag is just a ?snapshot? of a project in time.

[...snip....]

But wait a moment: isn't this tag creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a ?tag? is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch.
</quote>

NOTE the last line!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

On Tue, Apr 14, 2009 at 12:33 PM, Vincent Snijders > Another school says that you need to build releases from a tagged version. Those learners should go back to school! :-)

No. It's stupid to tag after a release is built or even worse, build from a branch. This makes it very hard to ensure that everybody uses the same revision to do its builds (e.g. FPC releases are build by probably almost 10 different people). It rarely happens that a release must be rebuilt but in this case the tag is simply moved by merging a certain revision.

Florian Klaempfl wrote

No. It's stupid to tag after a release is built or even worse, build from a branch.

That's what I meant. If trunk or some "release candidate" branch is stable enough to make a release, then tag that specific revision (a snapshot of a specific point in time). Now make a release based on that tag (and specific revision). Now that release is done and dusted
- never to be touched again. The same should be said about the tag.

If changes need to be made, a new branch should be created, revisions merged and patches applied. When it's tested and ready, tag it and create a new point release. Isn't this how 99% of the software projects out there work?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys schreef:
<quote>

Correct. Until the release has been announced, that directory should be considered a branch. After that is a tag set in stone. I admit I took a shortcut by merging the change. The correct way should have been:
* create a new branch from lazarus/tags/lazarus_0_9_26_2 to lazarus/branches/lazarus_0_9_26_2
* delete lazarus/tags/lazarus_0_9_26_2 (since the tag is not valid anymore)
* merge the revision from trunk to lazarus/branches/lazarus_0_9_26_2
* tag lazarus/branches/lazarus_0_9_26_2 to lazarus/tags/lazarus_0_9_26_2

Again: cumbersome.

I am abusing the tool, because it is a tool after all, not a law. Sorry to confuse you with it, but I never realized you would get into trouble with git. svn export and svn co of that tag works exactly the same after the release announcement (all the release builders were notified in private).

Vincent

2009/4/14 Vincent Snijders :

change. The correct way should have been

after a blocking issue was found in the tagged version.

Vincent

It's not that Git doesn't cope with it, it's just something unexpected even for a svn user. I would never consider doing a 'svn up' after I do a 'svn co' on a tag. As a long time svn user I always understood a tag as a single point in time with no modifications after it has been created. So if I did a 'svn co' before you did the merge to that tag, then if I spoke of tag 0.9.26 (expecting it not to change) if would be different to your tag 0.9.26. Hence my concern about the odd usage of tags.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

SubVersion had to be compatible with the old SVN, so that existing repositories could be moved easily.

We should distinguish between implementation and use of tags. Using tags for anything but immutable milestones is an abuse of the SVN features, and it's a weak excuse that "it's possible, so we do it" :-(

DoDi

And what if someone realizes that one patch is missing? Skip a release number? We will never to this again, we did this in FPC 1.0.x times and it caused a lot of confusion. Better a tag is moved ...

By SVN I guess you meant CVS? SVN is simply the command line tool for SubVersion repositories.

And WHY must SubVersion be compatible with CVS??? Git is a totally different design, yet importing CVS or SubVersion repositories is a no-brainer. In fact in all my years of using SCM software, moving repositories from SubVersion to Git was the easiest migration I have ever had to do.

We should distinguish between implementation and use of tags. Using tags for anything but immutable milestones is an abuse of the SVN features, and it's a weak excuse that "it's possible, so we do it" :-(

+1

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/14 Graeme Geldenhuys :

Then you did it before the release was announced and then you are on your own. Too bad.

Vincent

Florian Klaempfl wrote

And what if someone realizes that one patch is missing?

Well, is that not what "release canditate" or stable branches are for? Users at least expect updates and backports of patches in a branch. Then test, test and test! Once everything is working, create a release tag based on that branch.

Skip a release number? We will never to this again, we did this in FPC 1.0.x times and it caused a lot of confusion. Better a tag is moved ...

Isn't that what point releases are for??

* Release 0.9.26.
* Oh crap, we didn't test enough and 0.9.26 is broken.
* merge, fix and retest using the branch release 0.9.26 was based on.
* Release 0.9.26.1

....in the mean time new development continues on unstable trunk (0.9.27)...

If a release is broken one day after it has been released, then clearly not enough testing was done on that stable branch. In that case, release candidate branches should have a longer lifespan.

Just because a tag can have updates, doesn't mean it must. It goes against what most people know or expect and is even documented as such in the SubVersion docs. It simply adds more confusion. Once a release is out, it should be final. Point releases should follow from that to fix minor or overlooked issues.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Michael Van Canneyt wrote

Even in CVS - the mother of all revision systems - a tag could be moved, so there also it could be that you had to do a cvs up on a tag.

Software evolves (hopefully) and we should not repeat prior mistakes. ;-) See my previous post.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Even in CVS - the mother of all revision systems - a tag could be moved, so there also it could be that you had to do a cvs up on a tag.

Although it is rare that a tagged version changes, it can happen.

Michael.

Also, AFAIK the option in CVS was not there from the beginning and was introduced for repository maintenance, and required a "force" option. (And you aren't allowed to commit to tag so you wouldn't do it by accident... Does svn at least have a lock folder/branch command already?)

And as SVN revision ids are global/repository-unique, is there a reason to tag before compiling/testing like with CVS?

Best regards,
Fl?vio

Michael Van Canneyt wrote

You miss the point, namely that a 'tag' is just a convention between people. Nowhere it says that a tag should be set in concrete to last

Well to me and most other developers a tag is "a snapshot in time". And if you wanted something to move in time and merge, that is what branches are for. Why else would they have tags and branches? If they were meant to be used the same they would just as well just have created a feature called branches - and that's it (no need for tags).

'tags' have a different meaning to 'branches'. Everybody understands it like that and the documentation explains it like that. But Lazarus doesn't differentiate between it. Well you guys did in the past, but since last few releases tags are now handled like branches. So why do you you guys still bother with tags, just use branches then! At least then users will know to periodically do a 'svn up' on a stable branch.

That's how I see it, but now that I know you guys treat branches and tags exactly the same, now I know I need to periodically do a 'svn up' no matter where I am in the repository (and even if it doesn't make sense to me). :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

You miss the point, namely that a 'tag' is just a convention between people. Nowhere it says that a tag should be set in concrete to last unaltered for eternity. Every versioning software available provides a means to set a 'tag', and leaves it up to the users how to interpret 'tag'.

I for one would never use software that makes a tag irrevocable: Errare humanum est...

Michael.

To me as well...

Michael.

If you think it's so easy, be our guest to coordinate an fpc release :)

2.2.4 was heavily tested but then we recognized a security hole after everything was packed. Just as a hint: till all different versions of fpc for one rc are packed, it takes easily 2-4 weeks and lot of poking by the release coordinator :)

This is not really possible, the defines etc. in fpc are limited currently to x.y.z

So above.

I think this particular case is nothing to worry about. It is clear that tag moving is an exception made due to unfortunate coincidence.

As a general issue, IMO the "Discussion" section of git-tag manpage summarizes the case for correct tag usage very nicely ;-)

http://www.kernel.org/pub/software/scm/git/docs/git-tag.html

I agree, and IMO until the release is announced, a tagged version of the release in svn is not yet published (even though you can read it), so I am free to retag it. Until the release has been announced, I send the "I messed up" mail to the other release builders.

I wonder if I could make a tag unreadable for annomynous use in svn. It would be worth the trouble...

Vincent

It seems to me that in this discussion of tags vs. branches collectively we are not in disagreement about what tags are, what they mean, and how they were intended to be used.

What disagreement there is seems to be in how to manage a release. Specifically, the process of tagging a release and whether that process should be atomic and immutable or whether it can be adjusted, as necessary.

If the tool allows tags to be changed, then some see that as a useful option for adjusting a release that was, at first, incorrectly tagged. Others see such an action as a violation of the proper process for managing releases.

So, please let's talk about the discipline of managing releases.

If a branch has been designated as ready for release it should be tagged and announced. If that process was faulty - for whatever reason - what should happen? It seems to me that the answer to that question should be decided *independently* of the capability of the tools being used and also separately from the amount of effort involved. In other words, doing the "right thing" is always the correct choice and we should work toward making that easy to do.

Wow, I didn't know it takes that long. I can only comment on my experience with our software which gets released on two platforms. What I described is how we do things - your mileage obviously varies.

Oh, I didn't know that. Then again, I wasn't talking about FPC, this whole thread was about the Lazarus repository.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Alexander Klenin wrote

As a general issue, IMO the "Discussion" section of git-tag manpage summarizes the case for correct tag usage very nicely ;-)

And more importantly - in Git, a 'tag' is very different to a 'branch'. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/15 Graeme Geldenhuys :

Ah, so what is written about how to use tags with doesn't apply to svn, because with SVN a tag is not very different at all to a branch. ;-)

Vincent

Vincent Snijders wrote

Ah, so what is written about how to use tags with doesn't apply to svn, because with SVN a tag is not very different at all to a branch. ;-)

:-) I've only been using Git for 2-3 months (1.5 months actively). My understanding between the different usages of tags and branches pre-dates Git by many years. I have been a SubVersion user for many years. Git simply implemented tags the way most developers understood tags (branches and tags should not be the same thing). Maybe SubVersion 2.0 will fix the tag issue. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op dinsdag 14-04-2009 om 12:35 uur [tijdzone +0200], schreef Hans-Peter Diettrich:

You have never managed the release of a complex (open-source?) application, didn't you?

If a showstopper pops up, you have to cancel the release and make another. You can't release buggy software and then release a service-pack on the day the original release is released!

Joost

I dont expect so, since iirc they considered it the same (and I dont care).

Marc

Op dinsdag 14-04-2009 om 16:06 uur [tijdzone +0200], schreef Graeme Geldenhuys:

Dream on....

and then get back to the real world.

Joost.

ps: Releasing a fpc release costs more then 4 months! FOUR MONTHS! And still we had to cancel the release on the day of the planned release.

Joost van der Sluis wrote

ps: Releasing a fpc release costs more then 4 months! FOUR MONTHS! And still we had to cancel the release on the day of the planned release.

How did this thread become all about FPC releases??? This is the Lazarus mailing list as far as I know, and I was refering to the Lazarus repository - nothing to do with FPC releases. Please stay on-topic.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/15 Graeme Geldenhuys :

They show the real world example where moving a tag is desirable before a tagged version is published/announced.

What happens to a fpc release can happen (and happens) to a lazarus release too. For now the situation with Lazarus is not as serious as with fpc (2 months instead of 4), less platforms and release builders are involved, but still.

Vincent

Op woensdag 15-04-2009 om 11:25 uur [tijdzone +0200], schreef Graeme Geldenhuys:

The whole git-stuff is off-topic. Most people here don't care. But we do care about releasing lazarus and fpc versions. And both the Lazarus team and the fpc-team merged changes to a tag to make this happen.

And that's the thing you are attacking, merging to tags. The latest Lazarus release was a usefull example of this, but fpc used this also.

You can state that 'thou shoudn't do that'. I want to point out is that the two largest OS-projects I know did use this trick. (And we're not alone)

And you are all making fuzz about this being illogical and such, but you have only worked with tiny os-projects like tiOPF and fpGUI. Well, I can live according to some stupid rules for such small projects also. But we are talking about more complex things here.

As pointed out even in the git-documentation: these cases happen.

Joost.

Let's play it straight: there's no _need_ for moving tags. Yes, it can be convenient, but you'll shooting yourself in the foot no matter if it's "how private" you make it.

As I said previously (and was completely ignored ;-), with SVN one can rely on repository revisions.
And if people don't like that, they can use a series of "pre" tags. And probably a "pre" branch.

Don't take my word for it: ask the SVN list or cvs or cvsnt or some "change management" people what they think of moving tags...

-Fl?vio

It's one of the very first points in the SVN book (iirc differences to CVS), that branches and tags are the same.

And deliver and maintain a patch infrastructure for end users? Brrr.

I agree with Vincent that an ideal case would be to hide/unhide tags, so that they are only publically visible after finalization. But it remains only a tool, and such minor details shouldn't be exaggerated.

Moreover, I've a feeling that both Graeme and you are reasoning from a very centralized model, where one person is responsible for a branch, and often controls the total flow of patches over that branch. (like Linus, Andrew and the rest in Linux)

FPC and Lazarus are not organized that way. A tool should match organization, not the other way around.

2009/4/15, Fl?vio Etrusco :

I think I have to shoot myself in the foot before I give up this easier way of working.

Vincent

Marco van de Voort wrote

It's one of the very first points in the SVN book (iirc differences to CVS), that branches and tags are the same.

and then you read between the lines.... "design flaw!" ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/15 Fl?vio Etrusco :

Brilliant idea. Create a "pre-0.9.26" branch (or tag <yuck>) and start the release process. 2-4 months later if anything is broken, merge and patch that again and if all is well,
then create a "lazarus_0.9.26" tag (never to be touched because it's a released version).

How difficult is that??? Logically, Fl?vio's example makes a lot more sense that how it is currently done with moving tags.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Joost van der Sluis wrote

The whole git-stuff is off-topic. Most people here don't care.

I've setup a Git mirror of Lazarus SubVersion repository. It's got everything to do with Lazarus development. And yes most people don't care yet, because the Git mirror has only been public for a week.

I really don't give a rats ass about the tags in the Git mirror, because I always track the 'trunk' branch, though I am constantly a few revisions behind (when I find a stable revision). But I thought if others started using the Git mirror, they might require the tags in place - *hence* this whole damn thread. For completeness, I thought I would mark the tags, but then I noticed this very strange usage of tags.... the rest is history.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/15, Graeme Geldenhuys :

To me it feels bad, that in your proposal a release is *always* build from a branch and not from a tag.

In my / our current work flow, it is almost always created from a 'real' (never changed) tag and only in exceptional circumstances from a tag directory to which a commit has been made.

Vincent

Did you ever working on testing a lazarus or fpc release?

Very difficult. If a release is created from a branch, nobody can ensure that all release builders built the release candidate from exactly the same revision, if they don't, things might be broken when the final release should be built.

At cvs times we did this for fpc and we had to lock the branch to prevent commits (btw: can git lock branches ;)?), but nevertheless it caused confusion. So we decided to built from tags and move the tag by merging if really needed. Believe me, from 15 years fpc development, we've a lot of experience how to built a release of something complex like lazarus or fpc (fpc has even a defined release procedure, see http://wiki.freepascal.org/Release_Template)

In 1.0.x/cvs times fpc was built from branches and it was a mess, even using locking :)

Florian Klaempfl wrote

Very difficult. If a release is created from a branch, nobody can ensure that all release builders built the release candidate from exactly the same revision, if they don't, things might be broken when the final release should be built.

Why not tag it x.y.z-pre1 then, and if all went well, additionally tag the same revision
as x.y.z, otherwise create x.y.z-pre2 etc.?

At cvs times we did this for fpc and we had to lock the branch to prevent commits (btw: can git lock branches ;)?)

Git (and Subversion too) can, in principle, "lock" branches using pre-commit hook.
However, note that in git the whole problem does not exist, since in the normal workflow
nobody except release manager can commit to "release" branch anyway. Also, it you _do_ move a tag in git, everybody updating from your repository will
get a big fat warning ;-)

Florian Klaempfl wrote

> start the release process. 2-4 months later if anything is broken, > merge and patch that again Did you ever working on testing a lazarus or fpc release?

Do you mean... have I tested a release candidate when it was announced. It so, then the answer is yes.

Very difficult. If a release is created from a branch, nobody can ensure that all release builders built the release candidate from exactly the same revision, if they don't, things might be broken when the final release should be built.

You guys are talking in circles! Now you tell be that branches and tags are different, yet earlier I was explicitly told that tags and branches are identical in SubVersion. In in actual fact, there should be NO difference in creating a release from a branch compared to a release from a tag.

Form your quote above, nobody can ensure that all release builders have the exact same revision when tags are used either. After all, merges and patches have been applied to tags - exactly the same thing as is done to branches! This was EXACTLY the point I was trying to make form the start! Prohibit all read/write access developers from writing to tags. "pre-xxxx" branches will work perfectly and once all release builders are happy, THEN ONLY create a tag.

The point I made earlier. I checkout the tag "lazarus-0.9.26", then Vincent applies patches or merges something in there. I talk on the mailing list about tag "lazarus-0.9.26", when my revision is different from Vincent's revision.

At cvs times we did this for fpc and we had to lock the branch to prevent commits (btw: can git lock branches ;)?),

Yes, you use non-lightweight tags for that.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

What if you realize after x.y.z has been tagged, built and uploaded that it has a security hole as it happend with fpc?

Subversion has a native lock command ;) One can override it, but this is behaving really bad and I don't expect anybody to do so.

However, note that in git the whole problem does not exist, since in the normal workflow nobody except release manager can commit to "release" branch anyway.

So the release manager needs to run his own git repository instead of having the release tag in the central, fast and reliable repository? The sad thing about this workflow is anyways, that no release manager can test all patches because he lacks the appropriate machines so he needs to merge patches blindly.

Also, it you _do_ move a tag in git, everybody updating from your repository will get a big fat warning ;-)

This is fine, but sometimes moving a tag is needed. Period.

The answer is no, you never saw the things behind the scenes.

Prohibit all read/write access developers from writing to tags. "pre-xxxx" branches will work perfectly and once all release builders are happy, THEN ONLY create a tag.

The last time: everybody was happy, FPC 2.2.4 was uploaded and a day before it was announce, a serious *SECURITY HOLE* was detected, so we decided to bite the bullet and decided to fix, rebuild and move the tag. Now I stop it, you don't get it. But I see, you would have skipped 2.2.4, started over again with 2.2.6-rc1 and delayed the release of a new fpc version another 4 months ...

Vincent Snijders wrote

To me it feels bad, that in your proposal a release is *always* build from a branch and not from a tag.

Why? You guys just said that tags and branches are the same thing? Lets take the 0.9.26 release of Lazarus.

How I see the workflow (note I have no idea how you guys really did the 0.9.26.x point releases):

* create branch 0.9.26 (copy of trunk)
* start the release process.
* 2 months later all release builders are happy. now tag that branch as "release-0.9.26"
* trunk development continues
* We found some bugs in 0.9.26 release, so we backport some patch to 0.9.26 branch.
* 2 months later all release builders are happy with newly fixed 0.9.26 branch. Now tag it as "release-0.9.26.1". This denotes a point release because it builds on top of the previous 0.9.26 release.

In my / our current work flow, it is almost always created from a 'real' (never changed) tag and only in exceptional circumstances from a tag directory to which a commit has been made.

OK, under Lazarus's repository I understand that patches to tags are not the norm. It seems only the last few releases of Lazarus was affected by the exceptional circumstances.

Either way, I said what I had to say and created a few tags in the Git mirror, so I consider this thread done. We all agree to disagree on how tags and branches should be used in SubVersion.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Florian Klaempfl wrote

Very difficult. If a release is created from a branch, nobody can ensure that all release builders built the release candidate from exactly the same revision, if they don't, things might be broken when the final release should be built.

Why not tag it x.y.z-pre1 then, and if all went well, additionally tag the same revision
as x.y.z, otherwise create x.y.z-pre2 etc.?

At cvs times we did this for fpc and we had to lock the branch to prevent commits (btw: can git lock branches ;)?)

Git (and Subversion too) can, in principle, "lock" branches using pre-commit hook.
However, note that in git the whole problem does not exist, since in the normal workflow
nobody except release manager can commit to "release" branch anyway. Also, it you _do_ move a tag in git, everybody updating from your repository will
get a big fat warning ;-)

Distinguish between distribution lines. My suggestion is for the repository itself. A tarball can contain the patched version, and can have other naming conventions. RPM packages frequently come with patches. etc.

DoDi

What if, in response to a last-minute show stopper bug, the scheduled release was immediately superseded by another one with a higher release number? What would be the harm?

Do you really think that anyone likely to use these programs (FPC and Lazarus) would not be sympathetic and understanding about what happened and readily accommodate themselves to the fact that release x.y.z had a 1-day lifespan and that usable releases went from x.y.z to x.y.z+2? Especially if the explanation was readily available?

It's not like we are running out of release numbers or anything...

Also, I don't buy the argument that doing this would delay the new release another 4 months. After all, it would be the exact same code being released under the "move the tag" scenario so no additional delay would be needed.

Doug Chamberlin wrote

What if, in response to a last-minute show stopper bug, the scheduled release was immediately superseded by another one with a higher release number? What would be the harm?

It would make a lot of confusion.

The x.y.z release would never released, it would have a minus 3 days life span. Note that this thread is talking about the situation, where the source in SVN has been tagged for the release builders, but no release has been made public. The x.y.z release would go from x.y.z to x.y.z+4 (no odd releases, see
http://wiki.lazarus.freepascal.org/Version_Numbering) and you would have to explain the missing x.y.z+2, except that is visible in the svn history (I would delete the tag for the broken release from svn too).

Especially if the explanation was readily available?

Maybe.

Agreed.

Vincent

Doug Chamberlin wrote

What if, in response to a last-minute show stopper bug, the scheduled release was immediately superseded by another one with a higher release number? What would be the harm?

FPC did that once 1.0.8 in 2003 or thereabouts. Afaik I deleted the FAQ item about it only an year ago. Never again.

Also I've a bit the feeling that this whole discussion is a solution in search of a problem. There is no problem at all in the first place.

I am actually done chatting on this thread, but to reiterate your point. When last did you see a Windows OS being released and not have patches available in the first week of release. Even in open-source projects like Ubuntu. They day it gets released, there are updates to be downloaded. And with the Ubuntu LTS (Longe Term Support) versions they release point releases a few moths later - fixing even more bugs.

Why can't FPC release patches ( or new .pp, .inc and .ppu files) for those unexpected show stoppers. It would save the release builders hours of time. Note, this is only mean for those critical unforeseen / show stopper issues.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

You missed the days when we skipped 1.0.8, right? It was an faq for years: "where is version 1.0.8?"

It requires at least another release candidate to get the version number at all placed right (compiler, makefiles, docs, readmes, installers ....) and let it check by other people and to test if all defines are still correct. And the more release candidates you do, the more tired builders get, so times spans get longer and longer with every release candidate.

Op donderdag 16-04-2009 om 08:49 uur [tijdzone +0200], schreef Graeme Geldenhuys:

Well, you don't have any experience in building linux-distribution releases also, that is clear.

For distributions the same thing holds as for us: if a show-stopper occurs, the release is delayed. Last example is the release of Fedora 11 beta. It was delayed 2 weeks because of some show-stoppers. (2 weeks is very long, and believe me: nobody was happy with it)

But the point is that distributions only find issues 'show-stoppers' when the files concerned are on the cd's. And if they contain bugs in the installer, or security issues while installing Fedora. Thus: problems which may arrise before the patch-and-update mechanism is in place. (This was also the problem in the latest fpc release: it was only harmfull the first time you would run the installation-utility)

Distributions handle things like these exactly as how we do. Unimportant things can be done in patches.

Why can't FPC release patches ( or new .pp, .inc and .ppu files) for those unexpected show stoppers. It would save the release builders hours of time. Note, this is only mean for those critical unforeseen / show stopper issues.

Well, that's one of the reasons we made fppkg. But that's not something you do in a few weeks...

Joost.

Joost van der Sluis wrote

Well, you don't have any experience in building linux-distribution releases also, that is clear.

I never stated that fact.

Well, that's one of the reasons we made fppkg. But that's not something you do in a few weeks...

That is something I am very interested in especially for FPCUnit and fpGUI patch distribution. Hopefully soon I'll be able to take a closer look at fpmake and fppkg.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/