On 25.04.2025 09:29, ooRexx wrote:
Hi Rony, I think that is a good idea, I do not know of any bugs/features that are that serious
that they are /show stoppers?/ Anyone?
I can help with managing the build system next week. I will finalise my work
before then.
I propose that we set up the release candidate under */main/branches/5.1* rather than directly
under /main/releases. If we are not happy with the RC we can just replace it. Also it can serve as
the source for any 5.1.x releases later. When I look at the SVN tree this is what seems to have
been the strategy in the past. There is a 4.3 in /main/branches that never reached the
/main/releases for instance. Here is how it looks:
main
├── branches
│ ├── 4.1
│ │ └── trunk
│ ├── 4.2
│ │ └── trunk
│ ├── 4.3-old
│ └── 5.0
│ └── trunk
├── releases
│ ├── 3.1.2
│ │ └── trunk
│ ├── 3.2.0
│ │ └── trunk
│ ├── 4.0.0
│ │ └── trunk
│ ├── 4.0.1
│ │ └── trunk
│ ├── 4.1.0
│ │ └── trunk
│ ├── 4.1.1
│ │ └── trunk
│ ├── 4.1.2
│ │ └── trunk
│ ├── 4.1.3
│ │ └── trunk
│ ├── 4.2.0
│ │ └── trunk
│ └── 5.0.0
│ └── trunk
├── sandbox
└── trunk
There are also branches/releases for "doc" and "test" that need to be created at the same time. This
way we have all sources at the same level.
Note however, that the source is placed into "main/branches/x.y.z/trunk" and
"doc/branches/x.y.z/trunk", but for the test directory the trunk subdirectory does not exist, hence
"test/branches/x.y.z".
We could either leave that as is, add the sources to "trunk" in "test" ("test/branches/x.y.z/trunk")
or remove "trunk" from "main/branches/x.y.z" and "doc/branches/x.y.z". If changing the directory
structure we need to make sure that all scripts will continue to work correctly.
Any comments?
There is a /main/sandbox that is empty, is it allowed to put things in there? If so I could make a
test before we go ahead.
AFAIK no, "sandbox" is meant to allow developers to work on a feature off the main trunk. The
changes in the sandbox could be applied to trunk later or removed, if the sandbox versions are not
carried over.
There is still the problem that the rexx -v reports the SVN version number of the release. I
understand it should report something else (1?).
IMHO there is no problem with the revision number at all. It gets also reported
in .RexxInfo~revision.
Same goes for the naming of the built artifacts.
Not sure what you mean here.
Maybe this works if built under a different branch than trunk? Anyone with understanding of how
this works is welcome to explain, this was not solved for the 5.0.0 release.
Again, could you elaborate please?
Best regards
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
