JOSM versioning

[michael2402]

Currently, JOSM is versioned by it's SVN revision.

In the future, we want to version JOSM without relying on the JOSM version. For this, there will be two versioning schemes:

For tested versions, there will be a version of:
<year>.<month>

If we do tested releases for quickfixes (multiple tested per month), we use
<year>.<month>.1, <year>.<month>.2, ...

For latest version, we use:
<year>.<month>.<last tested minor + 1>-SNAPSHOT-<date>
e.g.: 18.11.1-SNAPSHOT-201811181423

We will have a build task to do the next development iteration (tag + update version)

For @since tags, we will keep them as @since xxx in source and run the replacement as soon as we do a release and then tag them with the official release version. We don't know the exact snapshot version when adding the @since tags, but since we often use branches there is no way of determining them.

Plugins can use the SNAPSHOT version to specify that they rely on an experimental version.

[simon04]

Replying to michael2402:

For tested versions, there will be a version of:
<year>.<month>.0

If we do tested releases for quickfixes (multiple tested per month), we use
<year>.<month>.1, <year>.<month>.2, ...

Remark: Ubuntu and the ​Linux kernel omit the .0 and start counting patch releases with .1.

[Don-vip]

Hotfixes are quite rare. We must obviously keep this possibility but I agree with can usually skip the .0.

I'm not a fan about keeping @since xxx and replace it by the "human version" only when releasing a tested version. In JOSM development model, "latest" version is a functional version as well, "tested" versions are only latest versions we all agree are in good shape enough to be used broadly.

I see two usages of the @since tag:

• for plugin maintainers, to see what JOSM minimum version is required
• for JOSM developers to quickly find the commit that introduced tihs public API two years ago

The second one is not so crucial. We can use svn/git blame to retrieve this information.

As we will need the timestamp information anyway, could we keep @since xxx in the commits and have a git hook replacing xxx by a timestamp when this commit is merged on JOSM master branch? Feasible?

[michael2402]

Replying to Don-vip:

Hotfixes are quite rare. We must obviously keep this possibility but I agree with can usually skip the .0.

Ok, that's fine then.

As we will need the timestamp information anyway, could we keep @since xxx in the commits and have a git hook replacing xxx by a timestamp when this commit is merged on JOSM master branch? Feasible?

So basically we would not add any version information but in the future, any @since tag simply defines the time at which that feature was merged into master?

The problem with git commit hooks is that they run on the client. They do not run at the server, so the time inserted would be the time that developer committed to his local store and not to the upstream repository. Basically, this is a good thing since it allows us to have mirrors of our main repository.

What might be able to do is use the post-receive hook to create a new automated commit (by a bot) as soon as a feature is merged into master that then updates the since tags.