openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject Re: procedure for going from RC to release
Date Sun, 03 Apr 2016 19:42:03 GMT
Carl Marcum wrote:
> I was looking at how some other projects handled "extras" things like this.

Other projects designed their trees in a different way.

> I found Maven uses sub-folders under release/maven for plugins,
> plugin-tools, etc, that don't go into their main release folder. [1].

Well, here the issue is: we have assumed so far that the OpenOffice 
project releases, well, OpenOffice. This will still be true, but about 
one user in ten millions will want the NetBeans plugin. We can't make 
things more complex for the other 99,99999% of users due to this.

So for example, one thing we can't do is to partition (now) our 
"openoffice" tree into "releases" (for the "real" releases) and 
"devtools". If we had known this years ago, it would have made sense 
even with the large difference in numbers.

In other words: I would consider
to be taken. There will be no "releases" subfolder created in it, to 
avoid large management costs for something 99,99999% of users won't use. 
Either we go for the dirty solution you advocate, where we mix release 
numbers and the "devtools" folder (which I don't like, but this is also 
not worth a long discussion honestly), or you place the plugin sources 
in some existing place.

> Should we use something like a devtools subfolder under
> release/openoffice so they don't have to be redone for each maintenance
> release of AOO or end up with multiples in each  AOO release?

Multiple? You will want to look up the distinction between dist and 
archive. If you don't find the relevant documentation, just ask and I'll 
dig it up from the website.


I don't know how going for the "dirty" solution will affect scripts. It 
will surely result in misaligned trees in dist/ and SourceForge but this 
is not particularly problematic. If I recall correctly the download page 
options are populated via JS, but in turn that JS is probably generated 
(by Marcus?) based on some tree inspection; so this would need a check 
too, to ensure the extra "devtools" directory doesn't get in the way.

On the other hand, the extra "devtools" folder will be ugly, but it will 
provide a container for all releases that are not related to our "main" 

We could at least agree that won't 
change at all with the plugin release, right?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message