[digester] 1.7.0 release

[robert burrell donkin <ro...@blueyonder.co.uk>]

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).

(most people will probably be aware that) i've decided to cut release  
again (potential release managers may want to take a look at this  
thread  
http://nagoya.apache.org/eyebrowse/ReadMsg? 
listName=community@apache.org&msgNo=3265) and that i've been pushing  
forward new releases for logging and beanutils.

the main motivation for these releases to enable downstream consumers  
of our libraries to have a smooth upgrade path which sidesteps binary  
compatibility issues with commons collections versions.

digester is the next in my sights for a service release. 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).

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.

(i know that i've promised to devote more time to digester a few week  
ago but all this blew up right to the top of my priority list.  
hopefully logging and beanutils are under control, so i'll be able to  
give more of my attention to digester soon...)

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] 1.7.0 release

[robert burrell donkin <ro...@blueyonder.co.uk>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] 1.7.0 release

[Simon Kitching <si...@ecnetwork.co.nz>]

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?

> 
> (most people will probably be aware that) i've decided to cut release  
> again (potential release managers may want to take a look at this  
> thread  
> http://nagoya.apache.org/eyebrowse/ReadMsg? 
> listName=community@apache.org&msgNo=3265) and that i've been pushing  
> forward new releases for logging and beanutils.
> 
> the main motivation for these releases to enable downstream consumers  
> of our libraries to have a smooth upgrade path which sidesteps binary  
> compatibility issues with commons collections versions.
> 
> digester is the next in my sights for a service release. 

That's good news.

> 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.

> 
> 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".

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org