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
https://dist.apache.org/repos/dist/release/openoffice
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.
https://dist.apache.org/repos/dist/release/openoffice/devtools/
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"
product.
We could at least agree that http://www.openoffice.org/download/ won't
change at all with the plugin release, right?
