EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #04052

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Antwort: Re: Bazaar-Plugins vs. New EPrint Versions

Good job Ian and Denis, but am i wrong thinking this requires, that the author of the plugin is still in progress or available!? Or who may include min_/max_version to the code?
A lot of Bazaar-Plugins were touched in 2011, 2012 for the last time :-( So perhaps the author is not in touch with EP anymore -  although his plugin would work for years...

In clear words: Who should decide? Thats what i meant with crowd-voting. This is actual feedback.

--
Jens Vieler
Informatikdienste
Universität Zürich
Winterthurerstr. 190
CH-8057 Zürich

mail:  jens.vieler@id.uzh.ch
phone: +41 44 63 56777
http://www.id.uzh.ch

Inactive hide details for Ian Stuart ---09.03.2015 10:05:43---On 09/03/15 08:48, Denis Pitzalis wrote: > Hi all,Ian Stuart ---09.03.2015 10:05:43---On 09/03/15 08:48, Denis Pitzalis wrote: > Hi all,

Von: Ian Stuart <Ian.Stuart@ed.ac.uk>
An: eprints-tech@ecs.soton.ac.uk
Datum: 09.03.2015 10:05
Betreff: [EP-tech] Re: Bazaar-Plugins vs. New EPrint Versions
Gesendet von: eprints-tech-bounces@ecs.soton.ac.uk




On 09/03/15 08:48, Denis Pitzalis wrote:
> Hi all,
>
> Maybe even easier would be to add a min_version and a max_version
> variables in the plugin definition. Like in PHP CMS. So we can define:
> $self->{min_version} = “>= 3.3.10”;
> $self->{max_version} = “< 3.3.12”;
>
> so we are sure that we always install the good version of a plugin.
>
> We could even go further and add a dependencies like:
> $self->{dependency} = “icon-builder>1.1.4”;
>
> etc
>
> What do you think?

The downside to this approach is that plugins should remain compatible
with all releases of EPrints (and certainly within a Version: 3.1; 3.2;
3.3;...)
The changes that kill plugins are changes to API calls... and those
shouldn't change within a version (so all function/api calls in 3.3.1
should still work in 3.3.14 - though there may be additional
functionality available within those calls, or via new calls)

I'd be happy with

$self->{min_version} = “>= 3.2”;
$self->{max_version} = “< 3.4”;

Anything else, and all Bazaar plugins automatically go "out of scope" on
every new release, until they are tested against an install of that new
release.

--

Ian Stuart.
Developer: ORI, RJ-Broker, and OpenDepot.org
Bibliographics and Multimedia Service Delivery team,
EDINA,
The University of Edinburgh.

http://edina.ac.uk/

This email was sent via the University of Edinburgh.

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/