I believe it was also suggested (Mark D. I think?) that we could use a similar
versioning scheme, just not tethered to the year, which would solve the
confusion of crossing annual lines. e.g. DSpace8 (vs. 1.8, etc.) might seem
cleaner and simpler to comprehend.
I think the only thing to consider would be to project it forward and ask, do I
like the sound of DSpace23. *shrug* Doesn't seem so bad to me.
--
sands fish
Senior Software Engineer
MIT Libraries
Technology Research & Development
sa...@mit.edu<mailto:sa...@mit.edu>
E25-131
On Apr 8, 2011, at 3:00 PM, Peter Dietz wrote:
Currently we've got 1.8.0-SNAPSHOT available, which corresponds to trunk.
Since the target audience of feedback on the pre-release beta's is
just the developer community, we can just announce in developer
channels, and update the demo.dspace.org<http://demo.dspace.org> server every
month and say
here are three cool features in trunk/modules. Perhaps even picking a
monthly featured module to showcase. i.e. May - webmvc, June - sword
client, July - rest api, .... So while really confusing to a general
user, a close knit group would understand that its just wild west
until 1.8.0.
For many projects, we might not have to do version bumps to get the
latest source, just svn up and rebuild. One weird aspect of
dspace-11.2 is that dspace-11 would come out in 2011, but 11.2 is
released in 2012. So there is something nice about a generic 1.5, 1.6,
1.7 numbering.
Peter Dietz
On Fri, Apr 8, 2011 at 2:29 PM, Joseph
<joseph.rho...@gmail.com<mailto:joseph.rho...@gmail.com>> wrote:
Dear Dspace Developers,
A couple of weeks ago there was a discussion at the developers meeting about
what to call the "Beta" release.
In one of the discussions in the dspace-devel list (I believe
about Asynchronous release) someone mentioned in passing something about
DSpace11 to represent the core release in 2011.
I like this idea, and since it was embedded within a larger discussion I
decided to bring it out here separate separately.
Since the idea of DSpace 2.0 is a bit muddled by the previous work on a 2.0
version of DSpace, I think a renaming of the release product could be a good
move.
>From the Proposed Roadmap to
2.0 https://wiki.duraspace.org/display/DSPACE/Proposed+RoadMap+to+2.0 it
looks like there is a planned major release every year; this would sync up
with those plans.
The minor (bug-fix) releases could still be denoted by the number after the
decimal point.(ex- DSpace11.1)
It may seem like a superficial change but I think it would add context to
the release name (Right now the context is that DSpace 1.7 comes after
DSpace 1.6), as well as break out of the (we're working towards DSpace
2.0-some version) loop.
With regards to the beta release, I think that adopting something like
Chrome's beta and developer channels might clear things up, where projects
graduate from one to the other, and then if a beta project has matured and
been tested enough by the time the Major release comes about, it might
graduate to the core.
I'm not sure about the details with module releases but I think this might
be enough to start a discussion.
What are your thoughts?
-Joseph
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net<mailto:Dspace-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
