On 5/7/13, Branko Čibej <[email protected]> wrote:
> On 07.05.2013 20:22, Olemis Lang wrote:
>> Sorry I missed this message ...
>>
>> On 5/7/13, Peter Koželj <[email protected]> wrote:
>>> Agree, at the minimum we need to get ticket relations working which are
>>> at
>>> least two weeks away. We need at least one 0.x release with working
>>> relations before proceeding to 1.0.
>>>
>> IMO , the fact that we are distributing changes that make the new core
>> and BH plugins substantially different from what we've been releasing
>> until now has significant relevance as compared to the fact that some
>> features have to be improved in BH relations , core and other plugins
>> . The next version will not be an straightforward continuation of
>> previous work but a major DB, and API upgrade . The version number
>> (i.e. 1.0) will make that fact obvious to users whereas alpha , beta ,
>> rc , ... will highlight that we are still working towards 1.0-stable
>> and are looking for further feedback , especially concerning plugin
>> compatibility after MP upgrades .
>
> How long do you propose to publish release candidates that are not
> actually release candidates because we know functional changes are still
> on the drawing board?
>
What are the functional changes ? BH relations ? If so , the way I see
it using all plugins except that one will result in a working system .
And we also have an initial version of BH relations plugin . Besides
if «at the minimum we need to get ticket relations working which are
at least two weeks away» then I see no problem in releasing 1.0-alpha
or 1.0-beta now , then release 1.0-rc1 in two weeks and 1.0-stable
shortly after .
> If you're worried about the "message to users" then by all means make
> the /next/ release 1.0 instead of 0.6, and let's make what I'd consider
> 1.0 be 2.0 instead.
Well , when I wrote the *suggestion* I was thinking of following that
1.x line from that point on . I was just trying to express my opinion
consisting on the fact that if I had to choose between any of the
following after reviewing what we have in trunk :
1. a substantially different code potentially incompatible
with some plugins (in the sense that we did not test them
all ... if any) that «we know or expect there to be problems,
but solicit testing from interested individuals.» or
«we don't expect there to be problems, but be wary
just in case.» [1]_
2. the logical continuation of what we have been delivering in
0.x series
... then I'd rather select (1) instead of (2)
Wrt to (1) at this very same moment considering the state of trunk ,
e.g. XmlRpcPlugin will not work 100% on product environments .
OTOH , what about upgrades involving plugin data ? There are tests , I
know . Nevertheless how many tests have been performed with real
plugin data when trying to migrate from e.g. 0.11 to BH 0.6 (<= which
is the version we have in trunk ?)
Below it's possible to see a summary of the state of an environment I
used (once upon a time) to test BH-specific UI improvements for Trac
PastePlugin following a suggestion of @rjollos . AFAICS it's running
BH 0.4 from sources in Ubuntu 10.04 . Three or so pastes included in
there .
{{{
#!sh
$ sqlite3 /path/to/testbh/db/trac.db
SQLite version 3.6.22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
attachment permission
auth_cookie report
bh_pastes repository
bloodhound_product revision
bloodhound_productconfig session
bloodhound_productresourcemap session_attribute
cache system
component ticket
enum ticket_change
milestone ticket_custom
node_change version
pastes wiki
sqlite> select * from system;
database_version|29|
initial_database_version|27|
bloodhound_multi_product_version|4|
tracpaste_version|3|
tracpaste_version|3|bh
sqlite> select * from pastes;
1|Do nothing|murphy|text/x-python|def nop():
pass|1359344460
2|Third paste |murphy|application/x-javascript|var x = 1;|1359360241
}}}
Now I try to upgrade target environment and this is what I get
{{{
#!sh
$ trac-admin /path/to/testbh upgrade
The upgrade failed. Please fix the issue and try again.
TracError: no such table: plugins_pastes_old
}}}
[...]
>
> The meaning of 0.x is fairly unambiguous -- it implies possibly massive
> changes in schema and API between .x and .x+1.
Just numbers ... that might carry some meaning [4]_ ... if we agree to do so .
> So let's not talk about
> confusing users, of which we only currently have early adopters who know
> how to deal with that, and let's instead /not/ confuse users and call a
> release 1.0 only when we're sure that we have all the schema, API,
> functional and UI bits polished to 90%. Which the proposed 0.6
> definitely isn't going to be, neither will anything that can be released
> by the end of this month, which we all know very well.
>
Well , the only way users could be confused is if they had any
expectations after installing 1.x (2.x , ... indeed, a given release)
, and all that as a result of some assumptions made by the Bloodhound
project by giving some meaning to version numbers after some agreement
is made in e.g. this mailing list ...
> What's this rush with 1.0 anyway? Is someone working towards a schedule
> that was not discussed on this list?
>
... so the point of my suggestion is not about the solely reason of
arriving to 1.0 . If we decide to give major release number [2]_ the
meaning of stability then I'd argue that we should be releasing 0.6 to
be consistent with that .
OTOH if we use version numbers to highlight API changes and
compatibility , after assessing the reasons I mentioned above then the
state of trunk looks closer to 1.0-beta than it is to 0.6-stable .
«Under this scheme, version numbers and the way they change convey
meaning about the underlying code and what has been modified from one
version to the next.» [4]_ This approach is similar to e.g. Python
[3]_ . I do prefer it since IMHO «stability» is a somehow subjective
indicator whereas API changes , compatibility and alike are concrete ,
and serve to the purpose of instantly identifying whether e.g. some
plugin will work smoothly against a given release and benefits of API
capabilities . For module authors for instance it is very clear that
Python 3 is another thing substantially different to Python 2 , maybe
even backwards incompatible or recommending upgrades for features to
be deprecated soon .
FWIW following the items in semantic versioning [4]_ doc , IMHO
(5) Our major public API consists in bep:0003 which has been defined ,
implemented and tested . version numbers would evolve
«dependent on this public API and how it changes.» [4]_ e.g.
BH relations API , which already exists but has to be improved ,
tested ...
(8) We have introduced some major changes to the public API
e.g. direct_db_query , direct_db_transaction, MP setup participants
with new semantics , a second kind of component manager ,
resource listeners , added fields in environment objects ,
introduced incompatible DB schema -especially for plugin tables- and
updates in web dispatch with impact on
TracStandalone , etc ... so, considering that model
we must be raising major number
PS: I'm just saying all this hoping we can make a explicit decision
about the meaning of version numbers and document it in a way similar
to [3]_ , [4]_ , [5]_ , [6]_ and [7]_ thus avoiding any future
misunderstanding and user confusion . AFAICR Trac model is similar to
[4]_
.. [1] Subversion release process - Release numbering
(http://subversion.apache.org/docs/community-guide/releasing.html#release-numbering)
.. [2] Software versioning
(http://en.wikipedia.org/wiki/Software_versioning#Change_significance)
.. [3] How does the Python version numbering scheme work?
(http://effbot.org/pyfaq/how-does-the-python-version-numbering-scheme-work.htm)
.. [4] Semantic Versioning 2.0.0-rc.2
(http://semver.org/)
.. [5] Bug Fix Releases
(http://www.python.org/dev/peps/pep-0006/)
.. [6] Module Version Numbers
(http://www.python.org/dev/peps/pep-0396/)
.. [7] Changing the version comparison module in Distutils
(http://www.python.org/dev/peps/pep-0386/)
--
Regards,
Olemis.
