[Building Sakai] [sakai-kernel] Version numbers.
Ian Boston
ian at caret.cam.ac.uk
Wed Feb 3 05:39:30 PST 2010
Just had a look at KNL-205, does that break anything, looks backwards compatible to me.
try dropping this into eclipse
public class TestAPI {
public void setContentLength( long length ) {
}
public void testContentLength() {
long longLength = 10L;
setContentLength(longLength);
int intLength = 10;
setContentLength(intLength);
Long longLengthObj = 10L;
setContentLength(longLengthObj);
Integer intLengthObj = 10;
setContentLength(intLengthObj);
}
}
I dont get any errors, warnings and even FindBugs on its most aggressive settings doesn't complain.
although you should *never* just delete methods from public APIs (ever)
You should deprecate first. eg
@Deprecated
public void setContentLength(int length);
public void setContentLength(long length);
With this change no one knows they might have a truncation bug.
Can you point me at the discussion on KNL-205. All I can find in Google is announcements from RSmart about it breaking binary compatibility ?
Thanks
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"
More information about the sakai-dev
mailing list