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

Wed Feb 3 09:18:37 PST 2010

Sorry but this is frustrating for me.  If we compare this to linux, the kernel is the kernel is the kernel. Linux has managed some pretty significant change over the years without having to change their artifact names - i.e. it is still the kernel.  To me this discussion we are having is theoretical versus practical.  Yes in theory we could imagine a conflict someday, somewhere. But, can we not just focus on the practical and move on with getting the work done?  If I am way off base here, please feel free to say so...  Thanks, L

Lance Speelmon
Scholarly Technologist

On Feb 3, 2010, at 10:56 AM, Ian Boston wrote:

>
> On 3 Feb 2010, at 13:33, David Horwitz wrote:
>
>> Ok thanks Ian,
>>
>> Looking at this discussion I wonder if we might be considering
>> different concerns, and as so in an effort to make sure we're not
>> talking cross purposes:
>>
>> 1) Internal package names. I see no real problem if both kernels
>> contain an org.sakaiproject.kernel.FooService
>> 2) published artefacts (this is where I see a problem) both shouldn't
>> have a org.sakaiproject.kernel.api.jar (for example)
>
> AFAIK there are no name clashes, all K2 artefacts are of the form org.sakaiproject.kernel.event because they have to be of this form in an OSGi environment.
> none of the Kernel 1 artefacts are of this form.
>
> The only potential name clash is "base" ( a pom artefact)
>
>>
>> These may interact in the OSGI space in ways I'm not familiar with.
>>
>> On the K1 roadmap - as you know this is a hazy area :-) The K1 team
>> has no plans that I am aware of of introducing non backward compatible
>> changes to k1. However as the >2Gb case that Anthony quoted the state
>> of K1 makes it imposible to say with any certainty that fixing a bug
>> would never require such a change in the next 2-3 years. In the case
>> in point it was unpalatable for schools running k1 not to have large
>> file support
>
>
> Agree 100% schools need the ability to stream files upto and over 2G, although you really need to support chunked encoding if you are serious about that. (AFAIK content hosting does not, but you might have fixed that)
>
>
>
>> but there was no way to do this without changing the API
>> in this way (fyi its a binary incompatibility)
>
>
> IMVHO.
> There is a perfectly normal way to manage the evolution of API's that has been released, you do not just go and delete methods,
>
> http://java.sun.com/j2se/1.5.0/docs/guide/javadoc/deprecation/deprecation.html
>
> And an example of API cleanup after several versions after deprecation
>
> http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg00125.html
>
> Note
> "
> RISKS:
> No risk since this method didn't exist in 3.2 and we checked that no
> references to
> this method exist in the Eclipse SDK.
> "
>
> Please don't tell me its Ok to delete API methods?
> Ian
>
>>
>> Regards
>>
>> David
>>
>> On 3 February 2010 15:18, Ian Boston <ieb at tfd.co.uk> wrote:
>>>
>>> On 3 Feb 2010, at 12:45, David Horwitz wrote:
>>>
>>>> I remain far from convinced but like Ian am probably to close to the
>>>> action to be the one calling this.
>>>>
>>>> Ian you mentioned that the k2 packages where changed after community
>>>> feedback, could you point us to that discussion so we could have a
>>>> look at the original reasoning? The only record I could find on this
>>>> list was:
>>>> http://groups.google.com/group/sakai-kernel/browse_thread/thread/5177414b60a4ac0a/024120c763574aa4?lnk=gst&q=package+name#024120c763574aa4
>>>> Dating from April last when you pushed the change to git (its quite
>>>> possible I missed it at the time)
>>>
>>> about 2 - 3 threads earlier.
>>>
>>> http://groups.google.com/group/sakai-kernel/browse_thread/thread/8d052ecd5317b003
>>>
>>> The change was suggested by Cris Holdorph,
>>> +1 Carl Hall (binding)
>>> +1 Anthony Whyte (?, binding at the time I think)
>>> yeah (I assume +1) Cris Holdorph (non binding)
>>> +0.5 Ian Boston (binding) on the basis I didnt care but I did the refactor
>>>
>>> At the time Anthony was on K1 and K2 and he voted +1 to the change. (he even signed his vote with his private key :))
>>>
>>> Just because we made a decision then doesn't mean we cant make another one now, nothing is cast in stone.
>>>
>>>>
>>>> FYI technicaly K1 is not under maintance but is in active (if quiet) delopment
>>>
>>>
>>> Ok, are you making API changes that are not backwards compatible as described and so require a major version number change?
>>>
>>> Ian
>>>
>>>
>>>>
>>>> David
>>>>
>>>> On 3 February 2010 14:27, Speelmon, Lance Day <lance at indiana.edu> wrote:
>>>>> 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"
>>>>>
>>>>> --
>>>>> 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.
>