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

Speelmon, Lance Day lance at indiana.edu
Wed Feb 3 04:27:16 PST 2010 

Given this latest information and the fact that K1 and K2 version numbers are unlikely to collide, I change my vote to -1 for changing K2's groupId.  Thanks, L


Lance Speelmon
Scholarly Technologist

On Feb 3, 2010, at 7:15 AM, Ian Boston wrote:

> The fact that you are creating changes that require major version changes, and breaks backwards compatibility worries me since that changes "maintenance mode" into "active development"
> 
> Even if you were in "active development" you would normally deprecate and support over at least 2 major releases before removing APIs and backwards compatibility, anyway regardless of that, you appear to have managed to release using a change from 1.0 to 1.1, but I think I can see where your coming from although I disagree that you should be introducing changes that have such a big impact earlier version of Sakai 2.x cant bind to later versions of the kernel and allow maintenance to continue.
> 
> ie, introducing a new method to an API will stop later versions of 2.x building with earlier versions of K1, but thats encoded in the poms anyway, but introducing a new method to an API should not stop an earlier version of 2.x binding to a newer version of K1 requiring a new set of numbers for maintenance. IMHO the major version means earlier versions cant bind, which is why K2 was K2, ie Kernel 2.0.
> 
> I have had time to think about this, changing the GroupID will mean changing the artifact ids and all the packages. It might not matter in Sakai 2/K1 with no classloader policy and generally accepted naming conventions, but it does matter in OSGi, and will add to confusion. Go and look at other OSGi projects, Look at all the Apache Projects. GroupId is always a stem of package name.
> 
> This is a patch to 15003 lines of code, and will move all the java files, require and significant rework in the documentation, configuration settings and other areas. Since I actually want to hit the next release I am -1 on this.
> 
> This puts the projects at loggerheads, since we both have an opinion and there is no answer we should take this to someone else to make a decision.
> 
> Ian
> 
> On 3 Feb 2010, at 11:18, Anthony Whyte wrote:
> 
>> 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 
>>> .
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

More information about the sakai-dev mailing list