openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: procedure for going from RC to release
Date Sun, 03 Apr 2016 22:19:59 GMT
Am 04/03/2016 10:10 PM, schrieb Carl Marcum:
> On 04/03/2016 03:42 PM, Andrea Pescetti wrote:
>> 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" product.
>> We could at least agree that won't
>> change at all with the plugin release, right?
>> Regards,
>> Andrea.
> Andrea,
> I hope you don't take my suggestion for disagreement.
> I was not the one who pushed for these to be official releases. I am
> just trying to make sure they don't confuse or interfere.

and that's great. So, thanks for asking these things. This shows us that 
you care about other things that maybe could be influenced by your work.


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

View raw message