Re: [Chicken-hackers] new release policy: adding my 2/100ths of a dollar...

[Matthew Welland]

** This is the opinion of an enthusiastic *end user* of chicken. **

Keeping up with change consumes time and energy on many levels. I would prefer to see periodic "releases" but I do understand that for those working on the bleeding edge maintaining releases is an annoying distraction.

Here is the classic "kernel model" that some end users (including me) would probably appreciate (just restating the obvious here for the record):

X.Y.Z (Y even) X.Y.Z (Y odd)

|

release-------.

| \

bug-fix => merge-bug-fix

| |

| new-feature(s)

| |

bug-fix => merge-bug-fix

| |

| new-feature(s)

| |

| /

release <------'

|

and on it goes!

The => are nicely handled by "propogate" or equivalent feature of your favorite revision control tool and of course merging (pull, push or sync) for converging the release branch and the feature development branch.

As a pragmatic approach I propose the dev team consider something like the following(*):

1. Bug are fixed by working on the release tree and are then propogated to

the development tree.

2. When propogating the bug fix to the development tree requires anything

more than a few minutes of effort and one or two conflicts then it is

time for a new release.

3. Releases do not go though any particularly arduous process. Tag the db,

put a tar ball out on the web site and call it done.

I think such a system is minimal burden and yet provides nice stable focal points for end users.

Thanks for reading.

Matt

--

(*) Assuming that the dev team is still considering options