Thoughts on a 1.8.0 Timeframe? 6 months? 9 months (same as 1.6.0->1.7.0)? 12 months?
Meeting Notes
Reflections on 1.7.0 release process, JIRA Review
Performed a JIRA review – ended with DS-645
Reflections on 1.7.0 Release process
Good:
Time-based release seemed to have worked well & we were on time!
Problematic / Could be improved:
Maven release issues – these are now fixed, and new Maven release process (via Sonatype) is heavily documented in our Release Procedure
Documentation processes – We need better processes/procedures for updating the new Wiki-based Docs. There was a quick scramble in the week before 1.7.0 to get all the necessary documentation in place.
Sharing Code & Earlier Feedback
General consensus that we'd like to (1) share code earlier, (2) get feedback/testing earlier, and (3) preferably get that feedback well before RC1, so that a feature has time to morph/change.
No agreement yet on how best to accomplish these goals. Several ideas came to mind (one or more of which could potentially be helpful):
Early "Beta" releases – these would be early releases of DSpace to show off one or more new features and give opportunity for immediate feedback. They'd likely need to happen one or more month(s) before the feature freeze & Release Candidate #1, so that features could change/morph based on initial feedback.
DCVS (e.g. git) – could be used to promote more early code sharing
Agile Release practices – could be used to establish intermediate/early deadlines ("iterations") throughout the year (e.g. separate deadlines for "beta1", "beta2", "rc1", etc.), to get us to try and get code out there earlier, and perhaps even allow for early "beta" releases.
We ran out of time and didn't get to discussion about timeframes for 1.7.1 or 1.8.0, yet
We are still looking for a volunteer to act as Release Coordinator for 1.7.1 and/or 1.8.0