On 5/10/2023 1:27 PM, Rick McGuire wrote:
On Wed, May 10, 2023 at 12:22 PM ooRexx <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
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.RickOorexx-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 _______________________________________________ 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
