New release/versioning policy

[Julian Kniephoff]

Dear Annotation Tool community,

as discussed in the meeting earlier this week, there will be some changes to how the Annotation Tool is going to be developed. Specifically, we are going to move away from the “rolling release” policy that was driving the project so far, and hopefully towards a more sustainable model. I promised a summary of the changes I have in mind, so here we go. Note that a few details still have to be worked out, and I will do so once I implement all the necessary changes in the project repository and everything that surrounds it. The general principles are pretty much settled, though, and we are at least going to try it for now:

* I will create a branch, probably called `legacy` or `stable` (depending on how I feel about it in the moment, I guess. xP Suggestions welcome.) with the **current state** of `master`.
* After a bit more, but not too much, testing of the Münster features, I will merge them into `master` and create another new branch, likely called something along the lines of `next` or `staging`.
* We can still (given enough time and funding, of course) fix bugs in `legacy`/`stable`. The motivation is to support people running the tool in production. We all know the tool is pretty buggy, and we don’t want people who can’t/don’t want to upgrade, yet, to have to fork the tool to fix their bugs.
* The same goes for `next`/`staging`, but this branch comes with an additional expectation towards the community to install this version on their test systems and test it thoroughly, preferably involving actual users of the tool. The code quality of the tool is unfortunately very low and there are now automated tests or anything of the sort, so big changes **will** result in bugs, and a lot of these bugs **will** slip through my amateurish clicking around in a tool that I don’t really use myself.
* At **some point** `next`/`staging` will become the new `stable`/`legacy`. (And at the same time, current `master` will become the new `next`/`staging`.) Support for the old one will end, and the expectation is that people upgrade. I don’t know when this point will be, yet, and I think we should just start by having this be a community decision contingent on how well people were able to test `next`/`staging`, the results of those tests, and how much has happened on `master` since.
* Bug fixes will regularly be forward merged from `stable`/`legacy` to `next`/`staging` and from there to `master`.
* New features and big refactorings can only ever go into `master`.
* Every big change that affects users has to be approved in the regular meeting. I would like this to be every change, but since the meetings consist mostly of non-developers and are rather rare, this is not feasible, I think.
* Pull requests need to be small or at least “regular” enough so that a complete review is feasible. This might necessitate splitting up a feature into multiple parts. What “small” and “regular” mean is up to my discretion for now. The point is: contractual/political/social reasons prevent me from doing so this time, but in the future I reserve the right to reject a pull request if I find a full review to be unreasonable. If you are developing a PR and are unsure, contact me, preferably with a draft PR; this is very much a “I know it when I see it” situation.
* There is a bit of an open question as to how this release model relates to Opencast. I think for now it doesn’t make sense to sync up the two in any way; the development velocities are just too different. (Ours just varies a lot.) Opencast releases still affect us, of course, because of compatibility. I hope that with more testing from the community, we will notice whenever things break sooner, and I will also look into how we can maybe automate or at least systematize this more. And then the goal would be to support as many Opencast releases as possible, as long as they are still supported by the Opencast community itself, in each of our three branches. This will not always be possible, and when and how we break this promise I would leave to the discretion of the community for now; it will probably depend on which Opencast versions adopters are running and/or are planning to run at that moment or in its near future.
* This is not really a rule, but a recommitment by ELAN/me to trying to make this tool better: What this model will allow me to do is make some necessary refactorings and actually **do** a proper review of the Münster changes, and make all the changes I find necessary in those, but in whatever time I need for it, without blocking users from using the new stuff already and without blocking new developments. Meanwhile with more user testing, we can already at least ensure the code is (more) bug free, if not perfect in the sense of a proper review.

I hope I didn’t forget anything important, and that all of these things are reasonable to everyone. They are all basically motivated by the following problems that plague this project:

* Limited developer resources. It’s basically just me, I always also had other projects, and now my job looks completely different still, so that dedicating the necessary long blocks of time proper reviews and development of new features are very hard.
* A very low quality, brittle code base that breaks when you add stuff or try to improve it, and simultaneously a lack in testing, be it automated or manual.

Watch the [repository](https://github.com/opencast/annotation-tool) closely in the near future if you are interested in how all of this is going to play out! For the next two weeks I will be on a very necessary vacation, though.

Looking forward to a hopefully brighter future,
Julian

--

ELAN e.V.
Karlstr. 23
26123 Oldenburg
Amtsgericht Oldenburg
VR 200644

Geschäftsführer: Dr. Norbert Kleinefeld
Vorstand:
- Prof. Dr. Martina Blasberg-Kuhnke
- Isabel Müskens
- Prof. Dr.-Ing. Gunther Brenner
- Prof. Dr. Ingmar Ickerott
- Dr. Marion Rieken