openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Marcum <>
Subject Re: procedure for going from RC to release
Date Mon, 04 Apr 2016 10:18:51 GMT
On 04/03/2016 06:17 PM, Marcus wrote:
> Am 04/03/2016 09:42 PM, schrieb Andrea Pescetti:
>> 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?
> of course. As you wrote correctly 99% of our users will not use the 
> plugin. And the remaining 1% are no users but devs. And these people 
> will use it directly from Netbeans anyway. ;-)
> So, I would see releasing the plugin as a part of the open source 
> promise: Everybody can have a look into the source code to see what is 
> going on - if they like to do it.
> Sure, I can implement also this pckage into the JS download scriping 
> and provide something on the download page. However, I really doubt 
> that it is worth the effort. ;-)
> OK seriously, Carl:
> - You can do whatever you see fit to release the source package 
> regarding filenames, directory structure or where to put it in the 
> tree on SourceForge. It will not influence the other AOO download 
> behavior.
> Adding it in the "source/" dir along with the other files is OK. Or 
> create a new "devtools/" dir.
> - When you have some documentation ready or just in mind, don't forget 
> to mention this source package incl. a link. Then we can proof that it 
> is available as open source.
> - As far as I've understood, the important part is the binary at 
>, right? Then we should keep the effort on 
> as low as possible as it is just for 1%.
> - And, finally, when we see that something was done wrong. OK, then 
> let's fix it at the lastest with the next plugin release.
> My 2 ct.
> Marcus

Hi Marcus,

Yes all these are source only. The binaries for the netbeans integration 
will be from and the bootstrap-connector and groovy UNO are 
Maven repo.


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

View raw message