exactly what perry is saying is the point. current plans point to
0.17, 0.18, ..., 0.23. given you need 2 months for each 0.XX, this
means 14 months to reach beta. this means productive mid 2004. and
this is NOT august 2002, as originally planned.
i suggested the following issues are critical:
730,668,1003,891,940
and i suggested to postpone issues:
1042,1044,1019,1034,1035,1036,1037,1046,1031,630,1015,1025,
510,639,1004,1008,913,1006,724,
495,992,837,699,919,990,933,787,869,971,977,751,774,957,951,
952,950,885,882,620,571,443,746,558,738,
838,749,773,852,959,850,650,667,997,854,986,752,991,777,
946,987,
these are not important for 1.0 cause:
1. they do not concern the stability
2. they are not specifications:
interfaces are specified prior to programming,
and NOBODY changes interfaces just like that.
3. internal "interfaces" are not interfaces
which count as interface to the outside world.
and please do NOT start a highly theoretical discussion about design,
goals, processes if the point is to postpone a bunch of issues, like
"fix python error in testcase 5345".
and please do NOT say "when we know there are significant changes
that still need to be made to achieve the base set of features."
without naming them or saying "issue XXX" would be such a thing and
don't think about saying that without reading the issue list.
i guarantee if you continue like this you will NEVER finish but you
will notice 0.17 would have been your 1.0 beta. and there is only one
valid reason for doing that: if your job depends on that.
svn has the major building blocks for productivity NOW:
1. easy upgrade in every now known case:
new client, new server, new db format (this is rare)
2. stable berkely db based server, no data loss
3. good architecture for even tackling the tom lord
issue list in future.
you just don't need to fix 2000 further issues and introduce 1567 new
bugs.
--- "Perry E. Metzger" <perry@piermont.com> wrote:
>
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
> > Julian Fitzell <julian@beta4.com> writes:
> > > And if people are holding off until 1.0, waiting for a
> > > stable interface that they won't have to put a lot of effort
> into
> > > updating for each new version, then it would be misleading to
> release
> > > 1.0 now when we know there are significant changes that still
> need to
> > > be made to achieve the base set of features.
> >
> > Wow, yes, exactly -- I couldn't have said it better. Thanks for
> the
> > concise explanation.
>
> Some of us are waiting for an official release to use subversion in
> our projects even though we could easily accept major changes in
> the
> interfaces (though not incompatible changes in the repository
> format
> obviously). If 1.0 is more than a few months off, could a stable
> release named .8 or .9 or something be created, with a "we know it
> won't eat your code, just don't expect upgrades to be painless"
> provisio? That is to say, "this is not beta code, but don't expect
> the
> same sort of interface stability 1.0 would mean"...
>
> Of course, if 1.0 were to happen in two months none of this would
> matter.
>
> Perry
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 2 12:22:39 2003