Apache OpenOffice (AOO) Bugzilla – Issue 127639
Write a script to assist with updating release numbers and metadata
Last modified: 2018-02-25 20:17:06 UTC
This task is suitable for new developers. Every time we prepare a new OpenOffice release, a number of files must be updated. We currently do it manually, but it would be great to have a script taking care of this. See https://bz.apache.org/ooo/show_bug.cgi?id=127552 for changes between 4.1.4 and 4.1.5, or simply https://svn.apache.org/viewvc?view=revision&revision=1765197 for a difference between 4.1.3 and 4.1.4. Task: produce a script in a language we support (ideally Bash and the standard Unix/Linux tools; but Perl, Python 2.x and Java can work too) that can be run to obtain the same effect as the manual changes shown above.
When looking at the files that need to be changed to generate a new version, then many parts are the same. In my opinion a consolidation makes more sense than to write a new piece of code to change much more code. Why not to use a central file for version information and point all mentioned files to this central file, so that the version data is spread to all need places. Here the mentioned files have to changed, too, but only once (e.g., to exchange the fixed data with variables). But the new script would change the files again and again and again and ...
Once things are automated they can be improved. If we had to tag new release now, we would go through a manual process once again. Making it automatic is the first step. Once something is automated, it is repeatable. And this means we can improve it and prove it still works as expected. But getting rid of manual updates is a step we have to take in any case.
(In reply to Andrea Pescetti from comment #2) > Once things are automated they can be improved. We both know that this will not happen. When the script is ready and working, then nobody will invest time to change the things again. ;-) > If we had to tag new release now, we would go through a manual process once > again. Making it automatic is the first step. When the manual process is wrong (and yes, it clearly is) then improve it. But automation is not the solution here. > Once something is automated, it is repeatable. And this means we can improve > it and prove it still works as expected. But getting rid of manual updates > is a step we have to take in any case. It will be always a manual step. It doesn't matter if you change the version number directly in the files or let a script do it. At the end you have to commit the changes it with a SVN command. Sorry but I stand by my opinion: The script is not the right way.
If you (anyone) are personally able to develop the better solution, just write detailed specifications for it and open a new issue, write a comment here and then and do it. In the meantime, this issue stays open as a simple, feasible, alternative that has some value in itself, since it will improve a very delicate and error-prone task.
I do not think we should let the perfect be the enemy of the good. Any step that reduces the risk of errors and omissions during the release process is a step forward.
I don't want to stop anybody here. It's just my opinion that I want to see expressed here.
The original architecture already has the structure Markus thinks we would need. The issue seems to be that for some reason the version number is not propagated through the complete build tool. And the current solution seems to me like a workaround. Since our current build environment is in question, I see a helper script to automate the current task as a better solution until we have replaced the existing build environment. Then we should again have a good maintained solution.
See https://lists.apache.org/thread.html/e7cc713961f65e791d34066ea4e540c18c73bed03ab1f727953e47a1@%3Cdev.openoffice.apache.org%3E for ongoing work.
Created attachment 86349 [details] script to update version of OO files A few words on how to use: - Execute like this : updateVersion.sh <version> <oo_path> where: version = the new version you want to add to the files oo_path= the path to the repo where you have the files. If no path is given, the script assumes current working directory - To tell the script what files to look for and what patterns you want to change you have to modify the config file like this: o You can simply add a file by name or by path o If you use file name the script will search for all files with that name and try to parse them o If you use path+file then the search will be faster as it will be more specific o You can add patterns to look for in each file by name or name=value (like what is needed in minor.mk) There are 2 things I still need to take care of: - See how to treat PREVIOUS_VERSION pattern (like found in openoffice.lst) and DATABASENAME - I want to expand versions given as input like 4 or 4.1 to 4.0.0 or 4.1.0. Currently this is not done
Thanks for your contribution! I played with it and it looks very nice. I like the updateVersion.config file approach. Nice and compact. Having it as a YAML file (or INI file) would look more modern, but honestly the current approach works without any external libraries or prerequisites and I must admit it's in line with the approach of other OpenOffice scripting - we rarely use modern features. So I don't see this as an issue. - Line 6: typo in script name (trivial) - line 17: since the scripts supports being run as an external tool, it would make sense to have it look for a default config in its own dir, using $0 appropriately. I mean, if the local one (from $PWD) is unset then try the external one (from the $0 container) before dying. - same code: we should probably die if $configfile is not readable - If we are going to normally run it outside main/, it is fine. Usually tools assume that they are run within main/, but so long as a check is added to ensure that the supplied dir (or, missing that, the current dir) contains a 'main/' subdirectory it will work. - We should also check that a version is actually supplied For the rest, executing a test with 4.1.6 everything looks fine, except this: --- solenv/inc/minor.mk (revision 1824713) +++ solenv/inc/minor.mk (local copy) @@ -18,8 +18,8 @@ # under the License. # # ************************************************************* -RSCVERSION=415 -RSCREVISION=415m1(Build:9789) +RSCVERSION=416 +RSCREVISION=415m10(Build:9789) BUILD=9789 -LAST_MINOR=m1 +LAST_MINOR=m10 SOURCEVERSION=AOO415 This is not OK since internally this means (piece-wise): RSCREVISION=415m10(Build:9789) 415 = "This is based on 415" - so it should be 416 m = Fixed shorthand for "milestone", stays "m" 10 = "This is milestone number 10" - this is wrong, in your case you will always have 1 here (it's milestone 1 of the new 416 series) (Build:9789) = This can be fixed later and it is obviously linked to the BUILD below, which should be increased but we don't have a logic for that so we can discuss it later So basically the only error is LAST_MINOR that should be reset to m1 (or anyway not increased), and RSCREVISION that is formed from it.
Hi Andrea Glad to hear it's useful. I will make the changes suggested and try to get back to you before the end of the week. Regarding minor.mk it seems there is a bit of a confusion on how to set the values in the config file . Let's assume your minor.mk in 4.1.5 looks like this (based on your example below): RSCVERSION=415 RSCREVISION=415m1(Build:9789) BUILD=9789 LAST_MINOR=m1 SOURCEVERSION=AOO415 To tell the script to do the right changes you have to add in the config file explicit values to the following 4 patterns only: RSCREVISION=416m1(Build:9790) BUILD=9790 LAST_MINOR=m1 SOURCEVERSION=AOO416 RSCVERSION doesn't require an explicit value since it can easily be covered by the regular logic, so that one is only mentioned cause it needs updating. These values must be explicitly written in there as i have not yet found the best logic to automatically update. The m10 and 415 that i put in my config were just an example. To better understand what i mean, just create a config file with only the following lines : --- file: minor.mk RSCVERSION RSCREVISION=416m1(Build:9790) BUILD=9790 LAST_MINOR=m1 SOURCEVERSION=AOO416
Created attachment 86355 [details] add corrections for initial comments All of the below are fixed by this version: - Line 6: typo in script name - line 17: since the scripts supports being run as an external tool, it would make sense to have it look for a default config in its own dir, using $0 appropriately. I mean, if the local one (from $PWD) is unset then try the external one (from the $0 container) before dying. - same code: we should probably die if $configfile is not readable - If we are going to normally run it outside main/, it is fine. Usually tools assume that they are run within main/, but so long as a check is added to ensure that the supplied dir (or, missing that, the current dir) contains a 'main/' subdirectory it will work. - We should also check that a version is actually supplied