action=version does not show wiki engine version
phkehl opened this issue · 12 comments
Hello
I'm not sure what your preference is, but I think action=version should show the wiki engine version.
I do see that this was easier with Subversion and its automatic
Regards,
Philippe
Ich habe eben mein uralt Wiki zur aktuellen Version upgradet.
Weshalb kommt da keine Wiki-Versionsnummer mehr?
http://funracer.ch/cgi-bin/rw/rkwiki01.pl?action=version
Ruedi
There was a related discussion. In fact, I think that we had it several times.
Right now it depends on the way you install Oddmuse. For example, the version is shown on oddmuse.org.
I think that the easiest solution is to create a separate commit for each release and then tag it. This commit will provide all the required version information. Then we can recommend people to use the stable version.
We were planning to create a new release soon, by the way. Good that you've reported this issue! Perhaps this time we will experiment on it a bit!
Another associated problem is that all links on the wiki are pointing to unstable versions. I don't think that this is correct. Right now I think that both I and Alex are a bit busy, so don't expect this to be fixed in a few days. Contributions are welcome though :)
But version information in a tagged commit – yes, we can do that, and I think that we will :)
Yeah, Alex Daniel is linking to the correct discussion. But here's the gist of it:
We have a make prepare target in the Makefile which will do the right thing if you run it in the source directory. It will create a copy of all the source file with their git tag for version information in the build directory. Ideally, we would offer a tarball of that folder instead of a tarball of the source tree for every tagged release. I wonder how we could do that for GitHub. Perhaps Alexine could do that on a commit webhook and offer the tarballs for download?
Just a note: there was a release but it does not fix this issue, which means that this issue will be fixed with the next one (perhaps the new release will be made just to fix this issue. That is, soon)
I'm thinking of simply doing this manually, for the moment. Building a tarball for every release and hosting it on oddmuse.org. Something like https://oddmuse.org/releases/ perhaps?
Ideally, there would be a make target for it. For every release in git tag --list greater than 2.3 it would check if the file ~/oddmuse.org/releases/oddmuse-$TAG.tar.gz exists and if it does not, it would git checkout $TAG && make prepare && mv build oddmuse-$TAG && tar czf oddmuse-$TAG.tar.gz oddmuse-$TAG && mv oddmuse-$TAG.tar.gz ~/oddmuse.org/releases/.
Now that I think about it, I guess we could have an extra step in there that organizes the files in the build directory – creating a directory for modules and a directory for translation files, perhaps?
And we need an extra step to sign those files, I think.
There is now a file stuff/release and a make target release that does the cheap thing I mentioned above. If we really want to check in the versioned code as previously discussed, we can now modify the release script and do just that. I'm not really trusting that git repo hackery, though. I'd still like to add some subdirectories and and a signature to my release script, though.
I agree that signing is a good thing. But does it mean that we can't make it easy to upgrade and switch between versions using just one git command? I'm not sure! Part of the reasoning is that files from oddmuse.org module pages should also have version information, which also means that having all that stuff in a git repo will make it much easier.
In other words, it seems like we should do both? I mean, git trickery and signed tarballs.
Well, signing is only required if we're going to offer tarballs for download from some source than GitHub. If we don't trust GitHub, we shouldn't host our code here. If we do trust GitHub, then there's no point in signing tarballs? Signing tarballs is only important if we're going to offer them for download from sites and mirrors such as oddmuse.org?
Well, but we should not force everyone to trust GitHub. I think that having a couple of alternatives is not a problem.
I rediscovered the old download area feature for Savannah. This is what it looks like: http://download.savannah.gnu.org/releases/oddmuse/
Here's some FAQ document explaining how it would work:
https://savannah.gnu.org/maintenance/DownloadArea/
https://savannah.gnu.org/maintenance/SharedDownloadArea/
An update!
@kensanata worked hard to fix this. We now have a download page. These tars contain oddmuse that was built (meaning that the version information is inside).
Separate modules are also available on the same page. Also, all links on the wiki were changed to point to these files.
This probably means that the issue is resolved now. Though we might wait a bit to make sure that all links are now pointing to stable files.
Everything seems to be alright :)