Page History

...

Agenda: (NOTE: This agenda is flexible, and based on discussions throughout day is subject to change)

...

...

• Background:
  • "DSpace 2" as a concept/version number has been floated for ~5 years
  • The definition's changed over time
  • Are we moving towards Dspace 2? Fedora-inside-DSpace == DSpace 2?
• Some Possible Version Numbering Options:
  • 1.8, 1.9, 1.10, 1.11 .... 2.0 (we decide when to make the major version shift to "2")
  • 8, 9, 10, 11 ... (drop the "1.", like Java)
  • YY.MM (eg. 12.11), like Ubuntu
  • YY or YYYY (e.g. DSpace 11 = 2011, or DSpace 2011)
• Scott: What's the problem we're trying to solve?
• Richard R: Expectations around 2.0, how close we are to it (as we approach 1.9, etc.), what we do to make it clear where 1.x is in relation to "2.0"
• Richard J: Shouldn't this be a marketing issue, not an issue for developers to figure out?
• Bram pointed out that encouraging sites to upgrade to the latest versions, and making those upgrades easy and painless, will result in more feedback and more interest from developers, and therefore more good code.
• Scott pointed out that even though 2.0 was "revolutionary" in its initial conception, in practice we've been evolutionary/incremental when it comes to actually releasing new features, versions, etc.
• Stuart pointed out that in recent years, we've been getting much better in terms of how often we release, restricting 1.x.1 releases only to bugfixes, etc.
• Over half the room raised their hand to "We don't ever want to release a 2.0". A good alternative being floated is to jump straight to 3.0 and then continue as normal, with major version reflecting major architectural change, and we know for the future that if we're planning big projects, we should use codenames instead of numbers!
• People who are currently happy users of DSpace and following current release will not care about new versioning schemes, and will upgrade in any case.
• There's a major opportunity in winning people again, who decided in the past that the DSpace product didn't fit their usecase.
• The Final Vote:
  1. 3 people voting for going from 1.x --> 3.0 (i.e. Skip over '2.x' version)
  2. 11 people voting for dropping major, eg. DSpace 3, 4, 5, 6 OR 9, 10, 11
     • By "dropping major" we mean moving from a "x.y.z" versioning to just a "y.z" versioning. So, rather than a 1.9.0, we'd just potentially call that "9.0" or we'd name it "3.0" instead
     • There was some indecision whether we should move to "3.0" after 1.x is done, or just drop the "1." and move right to "9.0", "10.0", etc.
  3. 4-5 people voting for date-based versioning (either YY or YY.MM)
• Wiki MarkupResults: 2.0 is gone, and we will move to a "\[major\].\[minor\]" numbering scheme (instead of \ [major\].\[minor\].\[subminor\]).
  • Do a strawman poll to find out exactly how the branding will work, whether we co-brand date and major number. (e.g. DSpace 3.0 (2012))
  • Feedback from others: We need to document our version numbering very well. What does it take to reach a "major" release, or do we just release a new "major" release each year. Needs to be clear to users what these version numbers "mean".
  • But the 1.x.y will definitely go, at some point. And 2.0 is definitely gone. RIP 2.0

...