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

Matt Campbell mkambol at gmail.com
Tue Jan 12 10:29:20 EST 2010

I'm definitely in favor of moving forward with a 3.2 branch.  Our own
release schedule will have us code complete around 3Q, and I've been a
little anxious about stability leading up to that point.

One question we had, though:  will Hudson be run against the 3.2 branch?
 We've come to rely on Hudson as a great source of feedback, both on the
current state of the build and as validation for our own checkins.  We
always make sure we have fully passing tests in our own environment, but
more than once now Hudson has revealed issues we needed to address.


On Fri, Jan 8, 2010 at 5:08 PM, Julian Hyde <jhyde at pentaho.com> wrote:

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20100112/1d563e3c/attachment.html 

More information about the Mondrian mailing list