db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: OJB maintenance branch
Date Mon, 10 Nov 2003 15:30:48 GMT

On Monday, November 10, 2003, at 06:04 AM, oliver.matz@ppi.de wrote:
> 1. When we make the next release-candidate rc5,
> we create a maintenance (1.0-)branch. This should be asap.


> 2. Bugs in the software that are present in that branch
> should be fixed in that branch


> 2b.  Bugs that appear in that maintenance branch
> that cannot or shall not be fixed there are clearly
> documented.


> 3. When we have the impression that the software in that
> maintenance branch becomes sufficiently stable, we release
> it as 1.0.0.  This may be done even though there are
> minor known bugs, and it should be done this year.


I agree with everything except "done this year." If it is stable enough 
for 1.0 this year, and I expect it will be, then we release it this 
year. If it isn't then we don't. I am willing to commit to busting my 
butt to get things out this year but am completely against requiring a 
release this year =)

> 4. Subsequent releases of that maintenance
> branch will be numbered 1.0.x for some x>0


> 5. The three new volunteers Lasse, rburt
> (sorry, what's your name?) and Michael get committer
> status and promise to commit only in the maintenance
> branch.


I don't like the idea of branch-specific committers. We trust them to 
commit or we don't. Having people take responsibility for components is 
good, and to be encouraged, but I don't like the idea of telling a 
committer they are not allowed to touch some branch. I am all for 
considering them as committers, but not pseudo-committers =)

> 6. All committers agree that no other changes than
> bugfixes are made in the maintenance release source
> code.


> 7. scarab issues should contain the version number
> somewhere in the title, as in
> "[1.0] ODMG transactions remove object from cache
> in single VM mode".  We should try to have
> scarab issues for every change we make to the code.


Why the title? I am not intimately familiar with Scarab but I sincerely 
doubt that it doesn't support a version field -- three year old 
versions of bugzilla do! Put the version in its own field. We really 
need to make Scarab (or some other system) less painful to use then.

> 8. rburt suggests that we have a dedicated website
> maintainer who is responsible for painting a clear
> picture of where the project is or what is
> outstanding as far as "issues" go.

+1 (+10) Matt Baird and I have had a few emails discussing the public 
image of OJB and this came up as a big issue.

> 9. The development in the trunc continues.  New
> features may be added and reasonable changes of
> behaviour may be made.  Subsequent versions are
> numbered 1.y.z for some y>0 or x.y.z for some x>1.


> 10. At some point of time in the future we decide
> that no further development takes place in the
> mainenance branch.  This might be the case when
> 1.1 or 2.0 is released.


This only works well when there is full API and configuration 
compatibility between versions. I am not interested in maintaining five 
maintenance branches down the road, though. so I suggest a general 
guideline of maintaining branches without forward API compatibility 
until there are no more bugs. If it is the *previous* release branch 
back port  all relevant fixes, if it is an older release branch just 
document it until someone complains that it is breaking their product 
(then encourage them to submit a patch ;-)

> (1) Who is responsible to merge the bugfixes and
> junit tests of the maintenance (1.0.x-)branch into
> the (1.y-)branch? He who make the fix or some
> designated manager?

In a commercial environment it is by far the easiest to have the 
developer who fixes the bug apply it to all relevent branches. As there 
is no one standing over us with a paycheck that isn't as easy to 
accomplish here. Still, I think that establishing a standard of "fix it 
in both branches" is ideal. If we make a habit of doing this than the 
practice becomes institutionalized and life gets easier.


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

View raw message