Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43A98B08.9010300@uidesign.de>
Date: Wed, 21 Dec 2005 18:04:08 +0100
From: Johannes Schaefer <johannes.schaefer@uidesign.de>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: releasing forrest 0.7.1  (Re: Releasing plugins (Re: svn commit:
 r358073 -
 /forrest/branches/forrest_07_branch/plugins/org.apache.forrest.plugin.input.simplifiedDocbook/resources/stylesheets/sdocbook2document.xsl))
References: <20051220190459.1594.qmail@minotaur.apache.org>
 <43A85F91.7060503@uidesign.de> <43A867C1.9030101@apache.org>
 <43A95385.1030305@uidesign.de> <43A987C9.5090004@apache.org>
In-Reply-To: <43A987C9.5090004@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


I was wondering if updates to released versions get "built"
and result in a new "binary" to download.

I do *not* mean plugins here (see discussion below),
I mean changes to forrest core.

Other OO projects do so, e.g. if there is a security issue
(e.g. Firefox 1.0.7, then 1.5).

When should such an update be done?
For critical bugs? After each "minor" comitt (like mine today)?

Johannes


Ross Gardler schrieb:
> Johannes Schaefer wrote:
> 
>> Ross Gardler schrieb:
>>
>>> Johannes Schaefer wrote:
>>>
>>>
>>>> Do these changes get back to the downloadable version?
>>>>  http://forrest.apache.org/mirrors.cgi#closest
>>>
>>>
>>>
>>> First of all, the plugins are not downloaded via the mirrors (this is
>>> something that we need to address at some point, but this is not too
>>> urgent since the plugins are typically very small).
>>>
>>> Secondly, plugins have a different release cycle from Forrest core. So
>>> these changes will only make it into the distributed version when we
>>> make a release of the plugin.
>>
>>
>>
>> Just to understand: if I'll break forrest 0.7 with a change to some
>> plugin I'll need to create a new version of it?
> 
> 
> I just added the following FAQ response to [1] (documenting as I go):
> 
> What if a new feature breaks compatability with a released version of
> Forrest?
> ------------------------------------------------------------------------------
> 
> 
> If you add a feature to a plugin that will break compatability with a
> released version of Forrest then you should up the forrest version
> number in the plugins build.xml file. This will prevent the new version
> of the plugin being made avialble to the older version of
> Forrest.
> 
> However, you might light to consider doing a release of the plugin
> before you break compatability. It depends on what other changes there
> are to the plugin before you start your work. It is always best to raise
> this on the dev list.
> 
> 
>>> How do we make a release? We're still in the process of specifying this.
>>> However, it will be essentially the same as a release for core, i.e.
>>> someone proposes it for a release, we vote, we release or not according
>>> to the vote.
>>
>>
>>
>> I've seen some of the discussion.
>> We'll need to relate the plugins to (released) versions of forrest.
> 
> 
> That is already done (see forrest version number in plugins build.xml)
> 
>>> However, it can still be used without a release. Let me explain.
>>>
>>> The current version of SVN head doesn't use plugins in-place yet. But
>>> what it does do is deploy the plugins from local src directories if they
>>> are not currently installed and no version number is provided for the
>>> plugin in forrest.properties.
>>>
>>> In addition, we can release unversioned copies of the plugin, which will
>>> then be installed to those users without the src. However, this is the
>>> part of the release process we have not yet fully worked out.
>>>
>>> So, what do you want to achieve? Continue the discussion down whichever
>>> of the above avenues you need to, lets work out the relevant process.
>>
>>
>>
>> We use forrest at customer's sites and I simply would like to point
>> them to the download page and say: get the latest release (update).
>> It's hard talking them into svn and stuff :-)
> 
> 
> If no vbersion number is supplied Forrest will always, automatically,
> download the most recent version of the plugin for the version of
> Forrest being run.
> 
> However, you should be aware that this may be a development version as
> things currently stand. I have been thinking of changing the behaviour
> slightly, so that if no version is specified the most recent *released*
> version is installed, if "-dev" is specified then the most recent
> development version is specified.
> 
> There is no need for the user to download anything. Forrest will do that
> automatically (unless there is an issue with write permissions or proxies).
> 
>> So, are the updates to the released forrest-0.7 brought back to the
>> binary distribution at http://forrest.apache.org/mirrors.cgi ?
>>
>> As far as I see: No.
> 
> 
> No, as I said before, the plugins are not mirrored. They are only
> available from the plugin download site [2], Forrest *automatically*
> retrieves them from there (but note, they are not upgraded
> automatically, the user has to delete the installed plugins for the
> upgrade to occur - another todo item [3]).
> 
> To get plugins onto the plugin site it must be deployed. However, when
> and how we can do this has not yet been fully agreed.
> 
> I just changed the plugin build system slightly. It is now possible to
> deploy a plugin or to release it. Deploying only uploads the
> unversioned, i.e. development, copy to the download server. Releasing
> uploads a versioned copy.
> 
> This means that you can now safely do "ant deploy" for the docbook plugin.
> 
> You update will be used by 0.7 Forrest (assuming that you have not
> broken backward compatability and therefore not updated the minimum
> Forrest version number). To have your clients update all they need to do
> is delete FORREST_HOME/build/plugins/PLUGIN_NAME and run Forrest as normal.
> 
> I hope this is getting clearer to us all, me included ;-)

yes, much clearer.
Will pose another question in new thread.
js

> 
> Ross
> 
> [1]
> http://svn.apache.org/repos/asf/forrest/trunk/plugins/RELEASE_PROCESS.txt
> [2] http://forrest.apache.org/plugins/
> [3] http://issues.apache.org/jira/browse/FOR-343
> 


-- 
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax  +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de

Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de