On 8 Jun 2004, at 02:01, Simon Kitching wrote:

On Tue, 2004-06-08 at 09:13, robert burrell donkin wrote:
i've been pleased to see that simon's been hard at work with TODO lists
for 1.7 and 2.0 (at least, i think it's simon - whoever it is, what not
create a user profile then we'll all know).

Yep, that's me. I see that some WIKI edits come up with the name of the person doing it, but I haven't been able to figure out how to do that. I can't see any "login" or "create account" or similar options anywhere on the MoinMoin pages. Can you point me in the right direction?

you sign in by clicking on the user preferences.

<snip>

since this is
release is primarily aimed at helping downstream consumers by resolving
dependency issues (rather than one aimed at adding functionality) it'd
probably be a good idea to move quickly to take a release branch
containing the current code base so that the work for the meatier
release (with more functionality) can proceed in parallel with the
release process (that's usually a little drawn out).

Well, there have been quite a few new features added in the last 12
months, and very few bugs have surfaced to be fixed. So as the current
release notes say it will be mostly a "feature" release if you use HEAD.
The existing CVS HEAD code is pretty stable and well tested, so I would
definitely recommend releasing from HEAD.


Having the new release reduce the dependencies will be nice.

The only developers who have added features to Digester for a long while
have been you and I (with pushing from Remy and Emmanuel in places). And
despite that TODO list, I don't intend to tackle any of those for at
least a month or so. So a separate branch for concurrent development may
not be necessary.

it's probably safest to use a release branch (since i'm not proposing to fix any bugs or do some of the other stuff that i'd usually do for a release). i plan to issue a release candidate for compatibility testing purposes, so releasing off HEAD would mean probably a code freeze of more than a week (which seems a bit long). using a release branch gives me more control and means we can start preparing for the bug fix/enhancements release whilst waiting for feedback on the release candidate.


if this seems like a good plan, i'll write it up (on the wiki) tomorrow
and move towards a vote on the plan pretty soon. as soon as we can
decide on the right number for the features release, i'll put an
outline release plan on the wiki.

That's great.

After an exchange of emails with Lars Kuehne I have decided to join in
with his "clirr" project (http://clirr.sourceforge.net/) after all, so
if I get *my* act together, we may even be able to include an API
differences and binary compatibility report generated by "clirr".

cool

- robert


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to