Provide detailed build instructions

[maystar]

I really enjoy using your app but I can just use the debug build provided in #7 to discover my servers in the network. That's why i really would like to recieve frequent updates for this app. Because of this and because I really like the idea of having an alternative to the playstore I suggest mupeace for the f-droid market.
https://gitlab.com/fdroid/fdroiddata/issues/83
It would be great if you if you could provide the necessary build instructions.

[eisnerd]

Thanks for your interest in this. The https://github.com/eisnerd/mupeace/raw/downloads/Mupeace-debug.apk link is not a one off but gives the latest successful build by Travis CI.

Travis can build this project automatically from a fresh clone in a clean Java development VM. The dependencies and steps not integrated into ant can be found in .travis.yml, which is slightly larger than I expect it would be if using maven or gradle. The only change for Play Store releases is running ant release not ant debug and using a signing key that I don't share.

This also means that an up to date apk is available within about 20 minutes of the code being finished. Like "nightly" builds on some projects, these are offered regardless of whether the code is a sensible candidate for release or tagged as such. There's no waiting for the night, though.

I should point out that almost everything you see in Mupeace is from abarisain and the contributors he credits. If you're interested in monitoring or perhaps contributing, at least feedback and ideas, to further Mupeace development, you could consider joining the Beta group that I'm going to try to get started.

[maystar]

Hey David,
Thanks for your reply! I've neither deeper insight into android build systems and libraries nor into scala. So it's not so promising to try to build mupeace if the f-droid maintainer was not successful. I'll link this issue in the f-droid issue.
I haven't really understand at which events the debug version is built. Is there any changelog or a log of build time stamps for both versions?
The Beta group sounds nice, but unfortunately I don't like join google+ at all for now. Perhaps I will one day, than I will participate your group! Would you also accept feature request in this bug tracker?

[eisnerd]

https://github.com/eisnerd/mupeace/commits/downloads lists all the builds. The messages name the branch that was built (generally just master or a tag on that branch) and also the commit hash. This can be followed on github to show the version of the code that was built, and the commit log will give you an idea what I was working on.

Also, you can paste those into the compare view for a changelog and complete source diff, e.g., between build 146 (a10ddfb) and build 150 (99b237a): eisnerd:a10ddfb...99b237a

Feature requests are very welcome. Someone may even like the idea and want to work on it. It would be helpful if they could be labelled enhancement or bug as appropriate when being raised.

I quite understand about g+.

[maystar]

I tried several recent debug builds from your link above with no success. Some of the apks refuse to install and the rest did not start. Just a message with something like "Please restart the application" appears on the screen of my Asus Memo Pad Hd 7. But restarts did not help as well as an uninstallation.
So now I'm back at the playstore version, which works fine. But unfortunately I can't figure out which build this is. Is there a relation between the github releases and the playstore releases? And what's the relation to the version number inside the app in the about view?

Do you have a hint for the f-droid maintainer who tries to build mupeace?
https://gitlab.com/fdroid/fdroiddata/issues/83#note_298521

[eisnerd]

They won't work on tablets yet. There's some relatively heavy development going on and I haven't brought all the layouts back into line yet. The major version number (i.e. 2 or 3) corresponds to a tag (i.e. v2 or v3). The second part counts the commits since the tag and the last part of the version number is a short commit hash to indicate exactly what code it was built from, so the production apk was built from 958dc4d.

I'll have a look through Boris' script and see if I can offer any hints. For me there has been no need to use maven for dependencies or to use a different versioning scheme. He's right that way I version the app does not fit well with F-Droid.

[maystar]

Ok, the versions then make sense. I was just a bit confused by the Readme.md file, where a roadmap to version 1.1 is discussed. So it's a bit outdated. I think it would be helpful for packager if you would provide a short changelog for upcoming releases with git hash.