Details
-
Test
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
0.7
-
None
Description
David Crossley wrote:
> Ross, are you able to explain what needs to happen with the plugins
> at release-time. I mean do they all need to have "-0.7" appended
> to the names of the zip files?
Blast I forgot that entirely (again!). Yes we need two zipped versions, a pluginname-0.7.zip and a pluginname-0.8-dev.zip
The system will then download the correct version for the currently installed version of Forrest. This will allow us to have a separate release cycle for plugins, if we deploy from a 0.8-dev version of Forrest then we will have the 0.8-dev zip file.
However, now I write that down I don't like it because there is no distinction between a 0.1 version of a plugin for Forrest 0.7 and a 1.0 version of a plugin for Forrest 1.0 (for example)
How about I change it to put the plugins in a directory so we have:
0.7/plugingOne-0.1.zip
0.7/plugingTwo-0.2.zip
0.8-dev/pluginOne-0.2-dev.zip
0.8-dev/plugingTwo-0.2.zip
We only allow *-dev plugins in the current *-dev branch of Forrest
We can worry about the release process for plugins after this release (just get them out there for 0.7, we can blow the trumpet on subsequent upgrade releases)
> Do we need to add something to our RELEASE_BOTES.txt file?
Yes, a section on plugins with a link to the plugins page, I'll add to project-info plugin
> Does someone need to tweak the build file?
Yes, leave it with me, I'll implement the above with whatever modifications people think we need.
Ross
(for follow ups see http://marc.theaimsgroup.com/?l=forrest-dev&m=111821546807300&w=2
> Ross, are you able to explain what needs to happen with the plugins
> at release-time. I mean do they all need to have "-0.7" appended
> to the names of the zip files?
Blast I forgot that entirely (again!). Yes we need two zipped versions, a pluginname-0.7.zip and a pluginname-0.8-dev.zip
The system will then download the correct version for the currently installed version of Forrest. This will allow us to have a separate release cycle for plugins, if we deploy from a 0.8-dev version of Forrest then we will have the 0.8-dev zip file.
However, now I write that down I don't like it because there is no distinction between a 0.1 version of a plugin for Forrest 0.7 and a 1.0 version of a plugin for Forrest 1.0 (for example)
How about I change it to put the plugins in a directory so we have:
0.7/plugingOne-0.1.zip
0.7/plugingTwo-0.2.zip
0.8-dev/pluginOne-0.2-dev.zip
0.8-dev/plugingTwo-0.2.zip
We only allow *-dev plugins in the current *-dev branch of Forrest
We can worry about the release process for plugins after this release (just get them out there for 0.7, we can blow the trumpet on subsequent upgrade releases)
> Do we need to add something to our RELEASE_BOTES.txt file?
Yes, a section on plugins with a link to the plugins page, I'll add to project-info plugin
> Does someone need to tweak the build file?
Yes, leave it with me, I'll implement the above with whatever modifications people think we need.
Ross
(for follow ups see http://marc.theaimsgroup.com/?l=forrest-dev&m=111821546807300&w=2