I agree with Rick here. But: the problem here is that the notions of GA, ‘golden’ are from the last century and might not be applicable in this day and age. I see a lot of software projects having two lines of release, one stable and one rolling. It is a fact, though, that there are companies still adhering to those older notions, some of them are ex-Open Object Rexx clients from IBM, and RexxLA has obligations towards those clients for maintaining and improving the product, on condition of which it was delivered the source code. The moment that the 4.X releases (our ‘stable release’) don’t work properly anymore, we are defaulting on that agreement. I might all be academic because those companies seem to be moving to other languages; that may or may not be our fault.
But whatever the state of the code, being in beta for 7 years is not a good sign for viability of any project. The problem here was declaring a beta, when in fact it was still pre-release code. For the future, we should refrain from calling a release a beta when we do not have a plan for a release. In my opinion, we need a plan to address this problem. It should be a plan to release on a specific date, on the condition that work has been done on a few issues. 1) What: Classify the open issues in ‘showstoppers' and ‘other’ categories. Flag them as such. Who: Rick and Erich, René. When: March 31, 2021 2) What: Commit all installers, tests and other improvements we have. Who: P.O., Rony and others. When: February 15, 2021 3) What: Identify documentation issues. Who: Rick and Rony, Erich, others. When: Februari 28, 2021 4) What: Improve documentation along identified issues. Who: Gil, Jon, René, Rony, Walter, others. When: April 15, 2021 5) What: fix, freeze, prepare and test GA release. Who: P.O., Erich, Rick, others. When: May 1st, 2021. I know I cannot decide on other people’s time, so I just hope we can agree to this, on a best effort base. I hope we all see the predicament we are in. When we have this in the past, we can decide on release approaches that are a better fit. Please react on, and improve on this planning, so we can have something we can commit to soon. best regards, René. > On 24 Jan 2021, at 12:39, Rick McGuire <object.r...@gmail.com> wrote: > > P.O., you have commit privileges now, so you ARE a developer. If you have an > install process working that is working through CMake working, then it should > be checked into the project. Having something that is your private setup is > not a working solution. You could be hit by a bus tomorrow, so our ability to > build an installer would go away. Having an installer available means any > interested person can checkout the code and follow the instructions to build > it themselves. > > That would be a big step, but the docs really need a thorough review. A lot > of new features in 5.0 (e.g., variable references) make portions of both the > reference and programming guide a bit dated. > > There are currently 83 open bug reports. A few of these I would consider show > stoppers, such as Walter's linein performance problems and the issues with > Windows file name case. A number of others are not in complete state, missing > needed tests and documentation. There are similar incomplete items in the > feature requests. This is not a release that is ready to go gold yet. > > Rick > > On Sun, Jan 24, 2021 at 5:54 AM P.O. Jonsson <oor...@jonases.se > <mailto:oor...@jonases.se>> wrote: > I agree with Rony that version 5 of ooRexx should be formally released, I > just did not raise my voice since this is a discussion amongst the developers. > > Due to the delay we may already have lost a major „client, my former > employer, the European Patent Office, with more than 4000 ooRexx 4 > installations. They are now going all-in for Python instead, they will never > be able to upgrade to 5.0.0 unless there is an official release. > > Can Rick and/or Erich provide a list of „showstoppers“ so they can be worked > off? Are there REALLY any problems that are so severe that they would > prohibit a release? I doubt it. > > I can offer to set up the macOS Installer on the Jenkins machine. It is Cmake > driven and uses standard Unix commands in the post-processing. It also > includes the latest documentation, license, HowTo etc. Example can be found > in „MacBuilds“ here > <https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0> > > I have also written test cases for all sample files, they can be uploaded but > require a little fix in the testing framework (that I can provide as well). > > I have set up the documentation (PDF and HTML) to be built on Jenkins every > new revision (this is where I get it for the macOS installer) what is missing > is an upload to Sourceforge, this needs to be done with someone with R/W > access there. > > So what is really missing that prohibits a release? Is it not about time now > to kill our baby and go ahead and release 5.0 and start working on 5.1? > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > >> >> _______________________________________________ >> 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 > 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
