[Mondrian] Mondrian release schedule (3.1.5, 3.2, and 4.0)

[Sherman Wood]

I have a large set of improvements to the Schema Workbench to check in
that I have been putting against the main code line. It includes a
dependency on olap4j for generation of MDX queries, which I can remove and
fall back to using the Mondrian APIs. The workbench distribution will
change to include olap4j.jar and asm jars to support olap4j. Looks like
this needs to go into the 3.2 and main code line.


Sherman

-----Original Message-----
From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
On Behalf Of Julian Hyde
Sent: Saturday, January 09, 2010 9:09 AM
To: 'Will Gorman'
Cc: 'Marc Batchelor'; 'Jake Cornelius'; 'James Dixon'; 'Mondrian developer
mailing list'
Subject: [Mondrian] Mondrian release schedule (3.1.5, 3.2, and 4.0)

> Will Gorman wrote:
>
> Before I kick off the Mondrian build I went to test Schema Workbench.
> When loading Foodmart, I get the following exception:
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError:
> org/olap4j/Scenario
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.
> java:124)
> 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> 	at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	at mondrian.rolap.RolapCube.<init>(RolapCube.java:246)
> 
> It looks like olap4j is now a direct dependency of Mondrian?  I don't
> think adding new dependencies to Mondrian in a patch release 
> is a great
> idea.  Should we consider rolling this change back out, or rev'ing
> Mondrian to 3.2.0?  
> 
> If the dependency is required, we'll have to modify Mondrian's build
> script to include this jar in the workbench distribution as well as
> updating all the other places where Mondrian is used in the 
> platform and
> client tools.

Oops. I had assumed that olap4j was already a dependency. I guess
previously
you'd only try to load olap4j classes if you used one of the olap4j
wrappers
(principally MondrianOlap4jConnection).

However, I'd rather not remove the scenario functionality, because I'd
like
people (in particular the PAT developers) to be able to use scenarios
before
4.0 comes out.

Now would be a good time to discuss the structure of releases between now
and mondrian-4.0. I've changed the subject of the email and Cc:ed the
mondrian list.

Here are the facts:

1. I am developing 4.0 functionality on the main line (//open/mondrian).
My
changes (and there are lots of them) are in a sandbox, not checked in, and
not on a branch.

2. The change to add support for scenarios (i.e. writeback) in the 3.1
branch (//open/mondrian-release/3.1) makes mondrian depend on olap4j.jar
for
the first time, even if you are using mondrian's legacy API. I'd call that
a
minor breaking change.

3. The code on the main line includes scenario support (and therefore
requires olap4j.jar on the class path) and one other minor breaking
change:
it includes the ability to have independent members of hierarchies in the
same dimension, which might just possibly break applications that have
used
multiple hierarchies.

4. Other developers are putting significant architectural changes into the
main line. I'm thinking in particualr of Matt Campbell et al's work on
NativizeSet. This is great work, and it doesn't break any APIs or
applications, but it's a pain for me to continually merge their changes
with
the 4.0 changes I am making in my sandbox.

5. At some point I am going to check my 4.0 changes into the main line.
From
that point, mondrian will be unstable for a month or so. (Not all tests
will
pass, and there will be significant breaking changes in API and other
behavior that we have not documented yet.)

6. At any time in the future, we may need to make a patch release at short
notice to solve a high-priority problem.

Given these facts, I don't think that we can continue to make
backwards-compatible releases in the 3.1.x series right up until 4.0 is
ready to go production. The differences between the code bases will be so
great that it won't be practical to port bug-fixes between the 3.1 and 4.0
lines. In addition, we need to make it easy for other developers (e.g.
Matt
Campbell) to contribute without continually treading on my feet.

I think the solution is to branch the current main line as mondrian-3.2.
(It
will become a //open/mondrian-release/3.2 branch in perforce.) We would
make
a series of releases mondrian-3.2.x. These would include scenarios,
independent hierarchies, and other recent contributions such as Matt's
nativization improvements.

This would let me develop 4.0 on the main line, and I can integrate
changes
over in one shot when 4.0 is close to being released.

We could optionally release mondrian-3.1.5 before then. I'd exxcise the
scenario stuff excised, so that it does not depend on olap4j.jar, but I
would not make any further releases from that code line.

What do you think? I'd also like to hear what other mondrian developers
think too.

Julian

_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian