Release tag in desktopnotifications plugin
-
Hi,
The last release tag in the desktopnotifications repo is v2.0.2, but a newer version has already been released (2.0.3.26+33.1, in my latest download). Could a release tag for version 2.0.3 please be added to the Git repo? I’m working on getting these plugins in Debian unstable, and these seemingly little things are important to get everything streamlined.
Thanks,
Roel
PS: If there’s a better place to file this type of requests, please let me know. There are some more coming up… thanks!
-
Final version is still 2.0.2
2.0.3 is the current master, so I wouldn’t worry about that.Difference is some translations updates:
https://stash.kopano.io/projects/KWA/repos/desktopnotifications/commits -
@marty said in Release tag in desktopnotifications plugin:
Final version is still 2.0.2
2.0.3 is the current master, so I wouldn’t worry about that.Difference is some translations updates:
https://stash.kopano.io/projects/KWA/repos/desktopnotifications/commitsHi Marty, I know the commits since 2.0.2 aren’t all that critical, but the version of the desktopnotifications plugin in webapp-3.5.8.2348+1319-Debian_10-all.tar.gz is 2.0.3.26+33.1, so it’s hard to see which source commit that was released from. Same for the intranet plugin. That one is released as version 0.1+40.27, but the source is tagged with v1.0.0. That makes it hard to do proper versioning of packages. Other plugins have the same issues…
Debian packaging tools work best if there is an upstream released tarball to work from, or a Git repo where versions are properly tagged, and the Webapp plugins seem to have neither.
Thanks, Roel
-
@rolek I’ll have a look.
-
@rolek Should be fine now for the mentioned plugins.
-
@marty said in Release tag in desktopnotifications plugin:
@rolek Should be fine now for the mentioned plugins.
Thanks for your help! It seems the intranet plugin still needs a proper tag, though.
It looks like the versions on the released packages are in most cases based on the last source tag plus the number of commits since that tag. Does that mean that the current master for webapp plugins is always considered stable? If not, it would be really useful to us downstream package people if you could ensure your release process includes a step where the commit that is used for a specific release is also tagged with the version number for that release. I know that’s not something to be done overnight, but if you are committed to having kopano packages included in distributions it would be a very useful thing to do.
Best regards,
Roel
-
Intranet plugin has version 1.0.0 same as the tag (master, pre-final)
Final package will be updated later when a new final is released.Master is not considered stable and the final release is always tagged with the version.
Some minor plugins are the exception to the rule, but this can (and should) be streamlined in the future.
