Create releases, and establish roadmap or similar plan for future releases

[mjordan]

In #370, @MarcusBarnes wrote:

I suggest that we start creating tagged releases of the code base (and documentation), running sample data through before each release as a double check between releases. That way groups of users have some expectation of what to expect with each release.

This issue is intended to encourage discussion on what should be included in the 1.0 release (or 0.9, etc. if preferred), and how we should plan for future releases (e.g., consensus, feature milestones, periodic, Semver, etc.). https://en.wikipedia.org/wiki/Software_versioning may be of interest in this discussion.

[mjordan]

@MarcusBarnes about running sample data through MIK before each release, I wonder if it's worth considering automating this. In https://github.com/MarcusBarnes/mik/wiki/Cookbook:-Automating-content-ingestion-workflows we have a shell script that can fire MIK and then check its output using the iipqa. We could scale this to run MIK using a bunch of different configurations. I'm not suggesting firing up a test Islandora and loading the data, just checking it with iipqa. We'd want to use input data different from the PHPUnit assets however. Might be a good way for us (or at least me, with iipqa) to eat our own dogfood.

If you think this is worth a try, let me know and I can proof of concept it.

[MarcusBarnes]

@mjordan I was thinking about automating running sample data through MIK (separate from unit tests) too, but wanted to investigate more into how to best implement this for ongoing quality control of the code-base. I'm open to your suggestion of using iipqa or other tools. Thanks.

[mjordan]

Another approach would be to use the one that https://github.com/mjordan/islandora_stack_tests takes. Even though PHPUnit is used as the framework, the tests themselves are not of PHP classes. Or, we could look at wring behat tests that do the same thing.

[mjordan]

@MarcusBarnes and I were chatting off-issue and we'd like to propose that we tag a 0.9.0 release soon (maybe after we close #421), then merge @whikloj's work on #424 into master. We focus on code cleanup and a few of the newer issues in master for a while (just throwing until end of summer out there as a possible timeline) and when we're happy master is stable we create a 1.0.0 release. The we can add features to master and indicate in the wiki docs that they are available now in master and will be in 1.1.0. We think this is consistent with Semantic Versioning and also lets us keep the wiki documentation up to date with both the master and next release version.

@bondjimbond @jpeak5 @whikloj and other MIK friends, what do you think?

[whikloj]

No objections from me.

[mjordan]

I did some work on #421 this morning and I'm thinking that we should cut our 0.9.0 tag before it gets into master (contrary to what I said in my previous comment), since it touches enough files that there are likely to be conflicts with #424. @whikloj if you want to rebase commits from #427 into #424, I think we can cut our 0.9.0 tag and then merge #424 in to master.

[whikloj]

@mjordan sorry I'm not understanding the process here.

You have merged #427 into master. So you can tag your commit now as 0.9.0 without me doing anything.

Then you can merge #424 into master and continue on with your work on #421.

But if you merge in #424 then you will probably have to rebase the work you have done (on #421) to allow it to merge into master.

But again, I can wait until #421 lands and then rebase #424 after.

One of us will have to rebase. Its your call which one. 😉

[mjordan]

@whikloj it's much more likely I am the one not understanding. Let's not worry about #421, since I'm not that far in. Tagging 0.9.0 now (with #427 having been merged) and then merging #424 into master after you have rebased changes from #427 sounds good. Does that makes sense?