On 20 January 2011 16:53, Brian Freels-Stendel <[email protected]> wrote:
> Our philosophy is not to be bleeding edge, so we generally don't jump
> on a .0 release, but we do want to remain semi-current, so a .1 is ok.
>
Hi,
This is a common perception (not just with DSpace, but most software), but
it's worth addressing in the context of how DSpace releases are managed.
The primary focus and planning of DSpace releases is on the .0 release. When
cutting a major version, we don't plan to do a .1, .2, etc. release. These
only happen if there are significant problems found in the .0 release (and
they may not even be problems that originated in the .0 release - quite
often they have actually existed for a number of releases, but have only
just been uncovered), which justify a .1 release.
For 1.7.0, we changed our release planning from "when it's ready", to
setting a date for the release well in advance and working towards getting
features into it. Going forward, we would hope to regulate that to become a
predictable cycle for the .0 releases. We're also including more testing in
the development process, and are looking to build community involvement in
the testing phases prior to the actual release (such as having longer
periods for testing, more test releases).
Between the quality analysis and testing in the development process, and the
tighter scheduling of major releases, it's quite possible that we will have
major releases in the future that have no .1 release, due to no problems
being found within a reasonable amount of time of the major release.
It's understandable to want to wait for a period of time before upgrading to
see if any problems are found, but anyone waiting solely for a bug fix
release may end up waiting for something that never happens (for all the
right reasons though!).
We also have a devil of a time with prerequisite software (we almost
> were not able to upgrade to 1.6 due to Ant, and we will have to wait for
> 1.7 because RH isn't offering a late enough version of maven.) We
> customize fairly heavily, and that is always a challenge, but almost
> always possible because of great community support.
>
Prerequisites are tricky, and we try as best as possible to support versions
of the major components (ie. Postgres, Java) that are supported and/or
provided on the recent major platforms (Mac, Windows, Red Hat, Suse, Debian,
Ubuntu). With distributions like Red Hat and Debian, they have a 'steady'
and cautious approach to new releases, so there will be times when that may
be impossible.
In the case of prerequisites like Maven and Ant, current versions can be
installed on any platform simply by unarchiving a file downloaded from those
projects homepage. And [particularly where it is just a development /
deployment tool,] it's quite easy to install and use a version that is
required by DSpace, and without overwriting the versions provided by the
platform. We would still rather be able to support the versions provided by
Red Hat, etc., but where we don't it's because we have good reason to
require features that are in the newer releases.
Regards,
G
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Dspace-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-general
