[sugar] Activity versioning schema
michael at laptop.org
Wed Jul 16 20:32:51 EDT 2008
On Thu, Jul 17, 2008 at 11:15:07AM +1200, Martin Langhoff wrote:
>On Thu, Jul 17, 2008 at 10:52 AM, Michael Stone <michael at laptop.org> wrote:
>> For these reasons, in my humble opinion, choosing our software packaging
>> format and guidelines (of which version numbering is but a single
>> aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an
>> off-the-shelf format. (I wish that the reality were otherwise).
>I understand the points you make, but - AFAICS - they don't have much
>bearing on versioning (by which I mean to say: the conventional
>RPM/Deb versioning scheme works fine).
I don't care too much what names people give to activities but I care
greatly about how the software that manipulates those activities is
written -- in particular, about the way that it makes use of those
names, both internally and in the UI. Thus, while I will likely be
content with any naming convention that might be proposed, I have
serious reservations about the quality of the software that will result
from the _procedures_ being used to choose that naming convention. Hence
my request that we perform at least basic diligence in checking that the
proposed naming scheme and its intended usage in software is consistent
with our largely unwritten requirements.
> They do impact packaging, but... they are not *that* special either.
My goal is to avoid deploying short-term hacks which complicate future
work. Hacks to conventions seem particularly dangerous to me because
they're the hardest things to change if you get them wrong.
As I said above, I will be happy if we choose to adopt an existing
naming scheme so long as that naming scheme is compatible with our
requirements and use cases. We just need to demonstrate that we are
aware of the consequences of our proposed scheme by checking that it
doesn't paint us into a corner down the road.
>> Do you require more justification?
>Ah well, I know notink of the XO so back to my cave where I try to
>reach my goals reinventing the _least_ wheels.
We have different resources to bring to bear on our respective tasks.
>Sorry about the noise.
I always (eventually) appreciate your input, even when I argue with you
or cut you off too quickly for want of the patience to find out where
you're coming from.
More information about the Devel