[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