[Building Sakai] [sakai-kernel] Version numbers.

Anthony Whyte arwhyte at umich.edu
Wed Feb 3 03:18:53 PST 2010


KNL-205 (support files > 2G), for instance, introduced an API change  
between K1 1.0 and 1.1 with a resulting incompatibility between minor  
kernel versions that some have argued should have prompted a K1 2.0  
release already.

Neither David nor I care if K1 1.0 minor versions increment beyond .9   
(e.g., 1.10.0, 1.999.0) .  What we are concerned about is being boxed  
in version-wise by the assumption that K1's APIs are fixed and  
unchanging and that K1 2.0+ releases are inconceivable.

If K2 changes it's <groupId> now the concerns regarding version  
collisions disappear.

+1 for changing K2's <groupId>
-1 for starting K2's version at 2.0 (start at 0.x or 1.0)

Cheers,

Anth




On Feb 3, 2010, at 2:10 AM, David Horwitz wrote:

> Ian,
>
> My concern is this, even at current rates of development the sakai2/k1
> world will be around for quite a while as schools run in hybrid mode
> or wait for Sakai3/k2 to mature to their needs. Its reasonably likely
> that to address a bug in k1 we will introduce some level API
> incompatibility. This should mean a new major version of K1, under
> your scheme that can't be done.
>
> I remain -1 for versioning k2 as 2.0 and +1 for changing the group  
> id's
>
> D
>
> On 2 February 2010 23:20, Ian Boston <ieb at tfd.co.uk> wrote:
>> Wow, this is weird, I thought this was a simple question, clearly  
>> not.
>> I thought (and hey I created it in the first place) we had Kernel  
>> 1.0 Supporting Sakai 2.x and Kernel 2.0 supporting Sakai 3.x.
>> At current rates you wont need 1.10 until 2020, there are plenty of  
>> software products that have more than 10 minor releases and AFAIK,  
>> its the '.' that important not the number of digits.
>>
>> BTW, we changed from org.sakaiproject.kernel2 to  
>> org.sakaiproject.kernel in the past, I think because the community  
>> told us to.
>>
>> Thinking about the release we just did, it should have been 2.0.2,  
>> which would have avoided the confusion.
>> Ian
>>
>>
>>
>> On 2 Feb 2010, at 19:37, Anthony Whyte wrote:
>>
>>> I recommend that K2 change it's <groupId> rather than choosing a  
>>> versioning strategy that boxes in K1 and limits it to 1.x  
>>> releases.  Plus, the K2 effort is so different in conception,  
>>> design and implementation from K1 that it should evolve naturally  
>>> along its own version path (0.1, 0.2..., 1.0, 1.1..., 2.0 ...).
>>>
>>> Anth
>>>
>>>
>>> On Feb 2, 2010, at 2:31 PM, Speelmon, Lance Day wrote:
>>>
>>>> I would tend to agree with David - separate groupId.  But maybe  
>>>> we change this post 0.2 release? Thanks, L
>>>>
>>>>
>>>> Lance Speelmon
>>>> Scholarly Technologist
>>>>
>>>> On Feb 2, 2010, at 2:16 PM, David Horwitz wrote:
>>>>
>>>>> Hi Ian,
>>>>>
>>>>> I would advocate having a separate group id. Naming the k2  
>>>>> release 2.0
>>>>> would then raise the possibility of a collision from the other  
>>>>> side
>>>>> (e.g. k1 2.0).
>>>>>
>>>>> David
>>>>>
>>>>> On 2 February 2010 20:54, Ian Boston <ieb at tfd.co.uk> wrote:
>>>>>> IHi,
>>>>>>
>>>>>> In uploading the 0.2 artifacts to maven I have notices that the  
>>>>>> K1 kernel and K2 share the same group ID. This is probably  
>>>>>> correct but will create a problem when we get to the 1.0 release.
>>>>>>
>>>>>> There are 2 options.
>>>>>> Change the groupId's
>>>>>>
>>>>>> Skip all the 1.x versions and got to 2.0
>>>>>>
>>>>>> eg 0.8,0.9, 2.0
>>>>>>
>>>>>> WDYT?
>>>>>> Ian
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the  
>>>>>> Google Groups "Sakai Kernel" group.
>>>>>> To post to this group, send email to sakai-kernel at googlegroups.com 
>>>>>> .
>>>>>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com 
>>>>>> .
>>>>>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en 
>>>>>> .
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the  
>>>>> Google Groups "Sakai Kernel" group.
>>>>> To post to this group, send email to sakai- 
>>>>> kernel at googlegroups.com.
>>>>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com 
>>>>> .
>>>>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en 
>>>>> .
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the  
>>>> Google Groups "Sakai Kernel" group.
>>>> To post to this group, send email to sakai-kernel at googlegroups.com.
>>>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com 
>>>> .
>>>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en 
>>>> .
>>>>
>>>>
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google  
>>> Groups "Sakai Kernel" group.
>>> To post to this group, send email to sakai-kernel at googlegroups.com.
>>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com 
>>> .
>>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en 
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to the Google  
>> Groups "Sakai Kernel" group.
>> To post to this group, send email to sakai-kernel at googlegroups.com.
>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com 
>> .
>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en 
>> .
>>
>>
>
> -- 
> You received this message because you are subscribed to the Google  
> Groups "Sakai Kernel" group.
> To post to this group, send email to sakai-kernel at googlegroups.com.
> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com 
> .
> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en 
> .
>
>
>



More information about the sakai-dev mailing list