Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Mon, 7 Jun 2010 12:05:34 +1000
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: Re: release process for our plugins
Message-ID: <20100607020534.GH40649@igg.local>
References: <20100527091644.GC54036@igg.local>
 <20100604010028.GB20607@igg.local> <008201cb0384$b2d326e0$187974a0$@com.au>
 <20100604024933.GC20607@igg.local> <012b01cb0567$acb9f6f0$062de4d0$@com.au>
 <20100607002740.GD40649@igg.local> <01ac01cb05db$11d01f60$35705e20$@com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01ac01cb05db$11d01f60$35705e20$@com.au>
User-Agent: Mutt/1.4.2.3i

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.