Re: [j-devel] Release Engineering planning (was Re: Repository copied to svn://common-lisp.net/project/armedbear/svn)

[Mark E. <ev...@pa...>]

XXXXXXXXXXXXXX wrote:
[…]
> So, in this case that would mean creating abcl and j tar and zip files
> for source distribution. After we have the old-but-unreleased code
> out, we can take the following steps:

What about a single source distribution for everything?  The "cost" of 
carrying around J is quite minimal, as long as we eliminate it in the 
binary distribution.  Having a single source for J and ABCL until more J 
advocates step forward increases the chances of finding same.


> - create a binary distritution for ABCL
> - split the j.jar file in an abcl.jar and a j.jar
> - create a binary release for J

I can get the ABCL build.xml to do that.

[…]
> 
>> 1.2 We create an easily extendable test suite for ABCL that includes
> 
>> 1.2.1 The ANSI tests
>>
>> 1.2.2 the stuff under src/org/armedbear/lisp/tests
> 
> Agreed.
> 
>> 1.2.3 What we need to gain confidence that our fixes for ABCL are not
>> messing up things that we thought were working
> 

Please see a candidate for [TEST-ABCL] ASDF wrapping

[TEST-ABCL]: 
http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/abcl-test.asd 


[…]
> That would be nice. However, I think the current tests/ directory is
> excluded upon j.jar creation.

I'll fix that when I get a build 'build.xml' to build 'abcl.jar' and 
'j.jar' from the commandline

> 
>> 3.  We start building releases with JDK-1.5 from Sun as the most common
>> JVM "platform" out there.  I can do older releases with JDK-1.4 under
>> ia32-solaris-5.11 if neeeded, but this would be in a special binary.
>> Something like Retroweaver (??) could help "back porting" anything we
>> end up doing with Java 5 specific features like Annotations, but I could
>> use some help here because I haven't regularly used JDK-1.4 since 2005.
> 
> Well, there's one problem with javac1.4, because I've introduced
> generics to silence compiler warnings about unchecked code: they are
> 1.5 level compatibility. Does your solaris 1.4 JDK support generics?
> 

I propose we only release post Java 5 compatible code from now on.  We 
should be able to fix the source by stripping out the annotations, 
right?  But I see this as a specialized build process done by somebody 
"who knows what they are doing".  I'd release such pre Java 5 binaries 
occasionally, but not sweat if they aren't available:   when people who 
want to contribute such release engineering step forward, we'll revisit 
this later.

[…]
> Having a MOP at all would be more of a priority to me than using the
> invokedynamic instruction, especially because that would bring ABCL on
> par with some of the other implementations out there. *Having* the
> functionality is required before you can work on the speed of the
> implementation :-)  However, what's great here is that this is open
> source and everybody gets to scratch his/her itch, meaning that if
> this is your priority, that's perfectly fine (and I'll support it too,
> btw).
> 
>> 4.1  ABCL 1.0 would run on Java 5

Then you're firmly in the "ABCL 1.0" camp.  I'm not going to waste too 
much time now thinking about "ABCL 2.0", other than to watch the results 
of the Sun VM Dynamic Language Implementation Workshop (Sep. 24 - 26 in 
CA) remotely.

Thinking of "ABCL 2.0" helps to evaluate the feature set of "ABCL 1.0" 
much more ruthlessly.

Mark <ev...@pa...>