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

Anthony Whyte arwhyte at umich.edu
Wed Feb 3 10:53:51 PST 2010 

Ian--If you decided to make a change I'd be happy to help out updating  
docs in Confluence and elsewhere as well as help sort out any repo  
housekeeping required.

Anth

On Feb 3, 2010, at 1:33 PM, Ian Boston wrote:

> David,
> Thank you for your support.
> The code change isnt too bad and if we only change the word "kernel"  
> can be achieved with minimal manual editing.
> The patch is large.
> I dont know what the wider impact will be, but someone (group of  
> people) is going to have to go through the docs on Confluence and  
> Sakai Kernel Google group looking for inconsistencies.
>
> Having seen what the 0.2 release did to the maven repo space, I have  
> sympathy with the K1 teams point of view, which is why I asked the  
> question in the first place.
> Ian
> On 3 Feb 2010, at 18:04, David Haines wrote:
>
>> My $0.02
>>
>> Nothing should happen that gets in the way of hitting the next  
>> release date.
>>
>> SInce K1 and K2 have grown apart in concept and implementation I  
>> consider them separate projects and they should have separate  
>> artifacts.  However I don't think it's reasonable to expect that  
>> the work would happen magically, so I'm willing to be part of an  
>> effort to make the change, provided other people would be willing  
>> to help too.  If there aren't enough people who think the change is  
>> worth spending their own time on then the change shouldn't happen.
>>
>> - Dave
>>
>> David Haines
>> CTools Developer
>> Digital Media Commons
>> University of Michigan
>> dlhaines at umich.edu
>>
>>
>>
>>
>> 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"
>>>
>>>
>>
>
> -- 
> 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