forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: release process for our plugins
Date Mon, 07 Jun 2010 02:05:34 GMT
Gav... wrote:
> David Crossley wrote:
> > Gav... wrote:
> > >
> > > When code has been changed on a plugin since the last release, are we
> > using
> > > the
> > > policy of 'lets upgrade the forrest version required as well as the
> > plugin
> > > version number' - that would make it easier all round. If that is ok,
> > then I
> > > can
> > > just go round all plugins that have had any code changes since April
> > 2007
> > > and bump
> > > their forrest version numbers to 0.9 ?
> > 
> > No. We are not using that policy.
> > 
> > The "forrestVersion" only gets incremented if there are
> > changes that "require" the current version of Forrest.
> > 
> > To do what you are suggesting would mean that users of the
> > released versions of Forrest would not get any plugin updates.
> 
> Ok, but the plugins when rebuilt will be done so with Java 1.5 , how
> will that affect things?

Ah good point. We should have done a deploy of all
plugins that had Java code (only some do) before
doing that change.

To answer, i don't know what effect it will have.

> It's been so long since some were updated that I guess they would need
> testing on 0.8 release before deciding if they are still compatible or
> not.

This is part of our past problems. We don't deploy those
plugins often enough and don't pay sufficent attention
to their version numbers.

Hmmm, i don't know what to do.

> > > Obviously any 'plugin releases' between forrest versions can just
> > have their
> > > 'plugin
> > > version' bumped - and for any of these we intend to start voting on?
> > (After
> > > this
> > > next Forrest release if I'm interpreting correctly)
> > 
> > Again only if it "requires" v0.9 functionality.
> 
> huh, Im talking 'plugin version' such as 0.1, 0.2, 0.3 not the 
> 'forrest version'
> 
> But I get it now I think, any total code changes that warrant a new
> plugin version number, such as any release would. Minor code changes
> whould stay at the same version number until there are sufficient to
> warrant a bump in number (i.e release) - And, if any of those code
> changes introduce 0.9 specific functionality, then we bump the 'forrest
> version' also. Therefore it is assumed the 'forrest version' number is
> the _minimum_ version we are saying it _will_ work on.
> 
> > Please see the explanation at
> > http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
> 
> Oh, how I've read that a million times these last couple of days.

Yeah, i understand. There are also some past dev discussions
where Ross explained it. Also there are some JIRA tickets.

> I have just updated the POD plugin - it had code changes from 2 years
> ago, + doc changes and references dispatcher related documentation
> examples that are or will be 0.9 specific, so I hope I was right in
> bumping both the 'forrest version' and 'plugin version' in this case. (?)

Bringing my comment over from that edit to try to
keep the discussion together.
http://thread.gmane.org/gmane.text.xml.forrest.cvs/9889/focus=27975
>
> Sure it may have been updated, but if its own functionality
> did not substantially change then leave its ""plugin-version" as-is.
> 
> Did it require new "0.9" functionalty, If so then also
> increment its "forrest.version".
> 
> By the way would need to also happen in the Plugins descriptor file
> e.g. plugins/plugins.xml etc.


Mime
View raw message