On 22.04.2024 17:06, ooRexx wrote:
On 22. Apr 2024, at 16:54, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
On 22.04.2024 15:24, ooRexx wrote:
is it ok to branch off and create folders in the Sandbox branch?
A "sandbox" is an area where experiments can be carried out. In the ooRexx project there are
subdirectories by the name of the developers, committers, such that one can use one own's
temporary subdirectories there to carry out the experiments.
Ok so I can set up something in /sandbox/PO for testing the Jenkins build modification automation
(switching from 5.1.0beta to 5.1.0 for ALL tasks in one go)
Yes, that would be possible.
Can they be deleted after a test? I wanted to make a 2nd short test for the next release.
There is quite a lot to add so I would prefer to delete it afterwords, using
SVN rm, is that possible?
That should be possible. Also, there is a shell interface to SourceForge which details escaped me,
where you would have secure shell access (ssh) and would be able to issue a "rm ...", however, I am
not sure whether one would be able to get to the sandbox directory.
Maybe Rick or Erich know that.
Also, in this context a question: When I look at what was done for 4.2 it appears that first two
workfolders were created:
.../docs/branches/4.2/trunk/
.../main/branches/4.2/trunk/
AFAICT these are meant to initially match the release versions. In the case that minor changes
are applied to a released version and a minor release is intended, then the changes should go to
branches. Once a release gets created from branches the new release would carry the version 4.2.1
in your example.
If you look at the folders it seems .../main/branches/4.2 was used as the working area before
4.2.0 was put in /releases. It could then also serve as working area for 4.2.1 and so on. I want
to avoid we had earlier where we discovered errors in CMakeList.txt when 5.0.0 was already in
/releases.
This is maybe a little bit hypothetical looking back at 4.2.0 which never was followed by a 4.2.1,
rather a lot of work and focus went into 5.0.0beta for years.
But once a release is made a branch with its version number should be made as well such that minor
fixes can ba easily applied to it in case an interim release would be regarded to be valuable.
and then, only at the end, the results were moved to
.../docs/releases/4.2.0/trunk/
.../main/releases/4.2.0/trunk/
Does it make sense to do the same for 5.1->5.1.0?
The release version number should always consist of three digits even if the third digits remains
to be 0. The reason being that ooRexx supplies all three digits and the name should reflect the
full version digits.
Se my remark above, I am talking about the situation where we have a release candidate that we
need to do documentation work on BEFORE it goes into the /releases branch.
Why not?
:)
HTH
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
