Opened 7 years ago
Last modified 9 months ago
#16870 closed enhancement
JOSM versioning — at Version 6
| Reported by: | michael2402 | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | hack-weekend-2018-10 | Cc: |
Description (last modified by )
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 (e.g. 18.11.1-SNAPSHOT) to describe the current latest snapshot for the given year, month and quickfix.
When publishing snapshots, the string SNAPSHOT is replaced by a unique identifier (e.g.: 18.11.1-20181118.142301-42).
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.
Change History (6)
comment:1 by , 7 years ago
follow-up: 3 comment:2 by , 7 years ago
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?
comment:3 by , 7 years ago
| Description: | modified (diff) |
|---|
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.
follow-up: 5 comment:4 by , 7 years ago
I wouldn't put SNAPSHOT and the actual date into the version. Since SNAPSHOT is at least in Maven a special string, we should treat it similar in our versioning system, that means:
- the latest snapshot version is always referred to as
18.11.1-SNAPSHOT(which version is actually used changes over time) - each snapshot is actually published with a version number like this:
18.11.1-20181118.142301-42(the 42nd snapshot, released on November 18th 2018 at 14:23:01)
That's also how the snapshots in our Nexus repository are currently versioned.
comment:5 by , 7 years ago
Replying to floscher:
- each snapshot is actually published with a version number like this:
18.11.1-20181118.142301-42(the 42nd snapshot, released on November 18th 2018 at 14:23:01)
Good point and good idea.
comment:6 by , 7 years ago
| Description: | modified (diff) |
|---|



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