db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tmcu...@midamerica.net
Subject RE: OJB usability - part 1 of 5: versioning policy
Date Wed, 15 Oct 2003 17:33:24 GMT
  You are correct, rather than just complain, I should also have presented
an idea for a solution.


  I would propose the following...


  1. That the current code be named BETA.

  2. That the current code be frozen.

  3. Before any more code work is done,

    a. a decision should be made as to which code is in its "Final Form". 
This code will not change.

    b1. A decision should be made as to which code is -not- yet in its
final form and needs more work.

    b2. A clear decision should be made as to what work needs to be done
to bring this code to a final form.


  4. Work to bring the decided upon code to its final form will then
continue.  Finalized code will not be altered.

  5. When all code is in its final form, then branch CVS for Release
Candidate 1.

  6. Decide on a period of time for Release Candidate 1 bug probing.

  7. Other than bug fixes, no new coding should take place in Release
Candidate 1.  Only changes which fix found or reported bugs should be
made.  No new features.  No new functions.

  8. When all bugs have been addressed and/or the alotted time for the bug
probe is up, branch CVS.

  9. Release 1.0 version

  9. The code in Release 1.0 should be frozen.  No changes will be made to
this code.

 10. Work can then begin in the head of CVS for development of the next
release.


  I believe that by doing this, a version will become available which
people can put into use and not have to worry about next weeks update
breaking it or working completely differently.  By doing the above, I
believe a more concrete final form of the functionality and features
will come forth that people can actually start using.

  If they then want to put the next release development copy on a test
system, they won't be as surprised or frustrated if it changes next
week, since it will, after all, be a development version.

-TMike

> My email was misunderstood -- I wasn't trying to call him to the mat -- he
> had some very good points about specific instances of code that could be
> modified for easier use. I guess I had assumed in order for him to have
> gotten that far in his analysis of the problems, he would have written
> modified code to have gotten to that conclusion. I was curious to look at
> his specific-recommendations for those problems.
>
> At the same time, I do agree that "Fix it yourself" is not always the best
> mantra, simply because you want to take into account design considerations
> for the entire project.
>
> Criticism is always good -- it is even better when a solution is presented
> at the same time.
>
>
>
> -----Original Message-----
> From: tmcurry@midamerica.net [mailto:tmcurry@midamerica.net]
> Sent: Wednesday, October 15, 2003 12:05 PM
> To: OJB Developers List
> Subject: RE: OJB usability - part 1 of 5: versioning policy
>
>
<snip>


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


Mime
View raw message