| 1 |
On Mon, Feb 02, 2004 at 11:06:12PM +0100 or thereabouts, Spider wrote: |
| 2 |
> a) 4 / year , retention 1 year... |
| 3 |
> |
| 4 |
> can we start with 2/year (we lag behind as is, we're notoriously |
| 5 |
> ungood with timetables. See 1.4 release before vouching anything ;) and |
| 6 |
> a 2 year retention? 1 year retention still feels "hurried" for much |
| 7 |
> enterprise use. Especially if you spend 4 months with forking and |
| 8 |
> building on it, then have 8 months of use-work, then have to restart. |
| 9 |
> (yep, reallife scenario) |
| 10 |
|
| 11 |
I feel it is important to align these release procedures with the rest of |
| 12 |
our release procedures. Since that is currently a quarterly release |
| 13 |
schedule, I'd prefer to keep this quarterly as well. |
| 14 |
|
| 15 |
> b) Updates and update distribution: |
| 16 |
> Updates should be distributed -separately- . once the tree is frozen |
| 17 |
> "stable" it remains so until the server goes down. updates to stable |
| 18 |
> builds should have an alternate path of exposure. This is another |
| 19 |
> requirement if any organization wish to track and work against a |
| 20 |
> distribution. |
| 21 |
> |
| 22 |
> supplying it as : |
| 23 |
> 2004-02-stable |
| 24 |
> 2004-02-updates |
| 25 |
|
| 26 |
I don't necessarily agree with this, but it's simple enough to provide a |
| 27 |
"2004.1-stable.tbz2" snapshot that people can use to have a totally |
| 28 |
unchanging tree. Then updates could continue to be distributed via the |
| 29 |
rsync mirror tree. |
| 30 |
|
| 31 |
--kurt |
Archives