[josm-dev] JOSM releases

[Ulf Lamping]

Frederik Ramm schrieb:
> The whole auto-update thing is a bit broken, or at least tends to
> break in the hands of stupid people like me. Several plugin ant files
> seem to automatically use the SVN revision as their version - not
> the *latest* revision, but the latest revision to affect the plugin. I
> updated a plugin, did "svn update", it said "at revision 1234", I
> updated the plugin page to say "revision 1234", but in fact the plugin
> build hat somehow decided that revision 1211 is applicable to the
> plugin, which led to JOSM constantly trying to download...
>   
I'm only guessing here, as I don't really know the way ant handles this. 
Did you update only the plugin sources or the whole svn?

I could think this versioning stuff only works if you update the whole 
svn tree - but again this is guesswork.

FYI: you can check the plugin version in the jar file by opening the jar 
using your favourite zip opener and look at the MANIFEST.MF file in the 
META-INF folder.
> Also, the plugins overview page in JOSM has me constantly puzzled as
> to what the buttons actually mean. 
>   
Time for some tooltips here (a *good* tooltip text is an invaluable 
source for instant help)?

BTW: What I most dislike of that dialog (once you downloaded a list of 
plugins) is the mix of currently installed plugins and available plugins 
fom the "outside", which is totally confusing IMHO.
>> In the end, anything other than taking a snapshot of the current trunk 
>> and release that won't work IMHO.
>>     
> But that would mean that, with a fixed release schedule of "1st of
> each month" or so, nobody would dare to add hot new features during
> the last few days of a month (or in fact nobody SHOULD do that, lest
> the whole idea of having stable vs unstable is only hot air).
>   
What I would like about a stable version is to point users to and have 
at least a good feeling that all is working together in that version 
(you will know the "current" bugs after a few mails).

In the end, I don't even see a big problem when to release happens. We 
don't have a beta test team and very few people actually willing to do 
the extra (and annoying) work to merge fixes between stable and trunk 
branches IMHO. So the best you can do is to release often enough to keep 
the pace of development and keep it bugfree as much as possible. If 
there are bugs that really annoy people a version "in between" the 
release cycle could fixed those. However, a release cycle of a month is 
a good rule of thumb to not be forgotten.

What's import: if you (or someone else) will send a mail to this list "I 
plan to release a new version on friday, anyone currently working on 
something and need to postpone it?". That people refrain from including 
the "hottest new features" on the planet: "I'm working on this super 
duper new xy, please let's include it and release on sunday" - and 
therefore will often introduce new bugs as this xy is not tested by 
anyone than the developer itself. That needs some discipline.

I guess we just have to try something out until we found a mode that 
works best for us ...

Regards, ULFL

P.S: If I added a new feature to mappaint I can live with a few weeks to 
see it in a new release (you can get the very latest plugin version from 
the wiki anyway if you're interested) - only the former release cycle of 
a few months were just too much.