Coming back to how to prepare a release: After what Rick wrote I have looked at the structure in the SVN tree. It seems a twig in main/branches is used to populate main/releases.
Example: /main/branches/4.1 has been used as the base for 4.1.0, 4.1.1, 4.1.2 and 4.1.3 releases in /main/releases /main/branches/4.2 has been used as the base for 4.2.0 release in /main/releases /main/branches/old-4.3 seems never to have reached a release status So the steps in a release should be to (i) copy a release candidate from trunk to /main/branches/m.n (ii) when it has been confirmed that the release candidate is a good one AND all the necessary changes have been made /main/branches/m.n ONLY THEN is the release candidate copied to /main/releases This provides the advantage that if we decide that we need to select another release candidate this is not a problem, we just replace the old one with a new one in /main/branches/m.n. There is also sufficient time to try out uploads and amending scripts before it becomes visible to the public. Does this make sense to all? Applied to 5.0.0 we need to copy the 5.0.0 release back to /main/branches/5.0 (not 5.0.0 or 5.0.1) and use it for preparing the next bug fix release. THEN, when there is time for 5.1.0 in the distant future we copy trunk to main/branches/5.1 and so on. Looking at the “release rate” for ooRexx 4 the minor bug fix releases have been 3 months to 1.5 year in-between, I interpret this as on a need-to-fix time basis. The major releases have been between 9 months to 2 years (longer time between the later releases). I have also looked at the documents that need revising I will put that into release-steps.md I have no knowledge on how to move/copy entire branches of the SVN tree, are there any volunteers out there? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 10. May 2023, at 22:50, ooRexx <oor...@jonases.se> wrote: > > >> On 10. May 2023, at 20:37, Gilbert Barmwater <gi...@bellsouth.net >> <mailto:gi...@bellsouth.net>> wrote: >> >> On 5/10/2023 1:27 PM, Rick McGuire wrote: >>> >>> >>> On Wed, May 10, 2023 at 12:22 PM ooRexx <oor...@jonases.se >>> <mailto:oor...@jonases.se>> wrote: >>> I am sorry but I have to come back to this item: >>> >>>>>> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? >>>>>> >>>>>> That indicates which release the change is going to ship on. Since the >>>>>> 5.0.0 has already been released, that should never be used again. 5.0.1 >>>>>> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0 >>>>>> release will contain new content, as well as bug fixes to 5.0.0 content. >>>>>> Bug fixes like this one should be applied to both the trunk and the >>>>>> 5.0.1 branch and the 5.0.1 milestone used. >>>>>> >>> >>> Currently we do not have a 5.0.1 branch in SVN, so it is not possible to >>> commit anything specifically to 5.0.1; all go into trunk which is then >>> uploaded to 5.1.0beta on sourceforge. >>> Sigh, it looks like an important item got deleted from the release process >>> check list. I know I highlighted this when we were starting up. At the >>> point where the release candidate gets moved from branches to releases, a >>> copy should have been made in branches with the fix level incremented (e.g. >>> 5.0.0 -> 5.0.1). That branch also gets the changes made to change the build >>> number to the matching level. The only updates allowed to that branch are >>> big fixes we wish to ship in a bug-fix release. No new features can be >>> added to this branch. It would be nice if bug fixes get applied to both >>> trunk and the bug fix branch at the same time, but it is not necessary. If >>> we choose to ship a bug-fix release, we can review all of the pending bugs >>> in trunk and apply the changes to the bug-fix branch as part of the release >>> process. >> It seems to me that we should immediately correct this omission and create a >> 5.0.1 branch. I will let others decide if it should be >> ...main/releases/5.0.1 or ...main/releases/5.0.1/trunk. It should be copied >> from ...main/releases/5.0.0 and the necessary changes made to reflect that >> the build number is 5.0.1. (Perhaps it needs to be in /branches until it is >> ready for release?) Then we need to review all the bug fixes in 5.1.0 and >> apply them to 5.0.1. As far as deciding to do a 5.0.1 release goes, I feel >> that there are some significant things that have been fixed that this is >> warranted. And it allows us to "correct" the missing pieces in 5.0.0 in a >> "clean" way as well. >> >> Gil >> > I agree that the 5.0.1 should be created, now when I know how it was intended > but we should at the same time agree on who does what. I can agree to take > care of Jenkins and the changes necessary to the build system but I will not > be able or willing to do any kind of SVN branching off, I would feel safer if > Rick and/or Erich agree to take on that part. I will then go through all the > things I have found so far and apply them in both places and I expect all > others to do the same with “their” bugs. I guess one would need to keep 2 > separate local SVN repositories then. > > Before any attempt is made at a new release I need to sort out what went > wrong the last time and find a way to automate the transition. I have some > ideas, when they are ready I will put them in the document Rick set up. There > is like a zillion things to change so the only way to do it is to automate it. > > /P.O. >> >>> >>> >>> >>> Are you saying that we should have branched off a 5.0.1 from 5.0.0? Where >>> should it have gone? Into >>> svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.1? >>> <http://svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.1?> >>> >>> I also looked at the revisions of all the twigs of .../oorexx/code-0/main/ >>> and it seems that although we froze 5.0.0 on revision 12583 there are >>> commits up to revision 12601, unclear how that can happen. >>> >>> 5.0.0 was branched off as <…>main/releases/5.0.0 whereas 4.2 and before >>> were branched off as <…>main/releases/4.2.0/trunk, is this significant in >>> any way? >>> >>> That was a mistake really. It just reflected how/where the copy was made >>> from. >>> >>> >>> Can all changes (5.0.1 and 5.1.0) stay in trunk? >>> >>> All changes should be made to trunk. As I mentioned earlier, it would be >>> nice if they would also get applied to 5.0.1, but that can be sorted out >>> when the decision is made to make a bug-fix release. >>> >>> Rick >>> >>> >>>> Oorexx-devel mailing list >>>> Oorexx-devel@lists.sourceforge.net >>>> <mailto:Oorexx-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >>> >>> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
