[Cuis] Cuis-Features

H. Hirzel hannes.hirzel at gmail.com
Sat Jul 6 00:09:24 CDT 2013


On 7/5/13, Ken Dickey <Ken.Dickey at whidbey.com> wrote:
> On Fri, 05 Jul 2013 14:26:15 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>
>> Cuis doesn't follow Semantic Versioning.
> ...
>> But I think we can agree on using "semantic versioning" like
>> version.revision numbers for packages and Features. Then we'd only
>> indicate dependence on version number (not revision).
>
> I see.  So requirements would not use revisions.  OK by me.
>
>> > Many packages are/will-be simple and requiring revision 0 is fine
>> > forever, but some will be complex enough that revision matters.  [IMHO]
>>
>> Mhhh. Not sure. To me, asking for SomeFeature-1.0 is not the same as
>> asking for SomeFeature-1.*, as the former is a specific release while
>> the latter matches a whole series.
>
> The prototype code just has version as equal-or-less and revision as
> equal-or-more.  So a revision of 0 is a * but without the cost of pattern
> matching.  For me, revision 0 means any revision greater than or equal to
> zero.
>
> I see that this is not clear from the interface.
>
>> > The constructors could certainly have short forms with the obvious
>> > default(s).  I would expect the following to be the same invocation:
>> >
>> >    (Feature named: #Sound) require.
>> >    (Feature named: #Sound version: 1) require.
>> >    (Feature named: #Sound version: 1 revision: 0) require.
>>
>> No, to me, default is nil or *, i.e. "anyone will do", while 1 or 0 are
>> specific.
>
> I think I see where you may be heading.
>
> Perhaps using the current interface for fixed (equality) requirement and
> better naming for ranges:
>
>   (Feature named: #MrCool version: 2) "versionEqualTo:"
>   (Feature named: #MsCool versionRange: 1 to: 3)
>   (Feature named: #TooCool version: 3 revisionAtOrAbove: 15)
>   (Feature named: #ImCoolToo versionRange: 3 to: 4 revisionAtOrAbove: 15)
>
> The idea being to avoid the need for a pattern language for version/revision
> specs and hide the details in the implementation.

+1

> This would certainly be a more useful/clear interface.
>
> Hey, I would be less confused. ;^)
>
> Cheers,
> -KenD
> --
> Ken [dot] Dickey [at] whidbey [dot] com
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




More information about the Cuis mailing list