Release number change of plans for Xalan

[Scott Boag/CAM/Lotus <Sc...@lotus.com>]

As most of you know, Xalan 1.0.1 turns out to be not compatible with the
recently released Xerces 1.0.4, which has stirred the pot a bit for our
next release plans.

For background, here is how we define our release numbers:

=============
Xalan releases will use the notation Xalan/i v.r.x

The values of i, v,r, and x had the following meanings:

i is the implementation, either J for Java, or C for C/C++.

v is the version number. The version number will change only when there is
a significant, externally apparent enhancement from the previous version.

r is the release number. The release number will change when a new set of
functionality is to be added, e.g., implementation of a W3C specification.
Release changes also typically indicate an API or behavior change.  [It's
my assertion here that a change in external dependency should also require
an upgrade in release number.]

x is a drop number indicating a change to the release.  A drop number can
be either [Dxx] defining a Development release representing progress
towards completing a release(r); or [.xx] defining a maintenance drop for a
release(r).
=============

I'm not sure how closely we really have stuck to the exact letter of these
definitions in the past, but that is the idea.

Because an upgrade to Xalan to match Xerces 1.0.4 will *require* you to
upgrade to Xerces 1.0.4, we feel we should upgrade the release number.
Also, Xalan 1.1.x is turning out to be a much greater change that we
originally anticipated.  Therefore, we feel we should schedule the
following releases thus:

*  Xalan/J 1.0.2, etc., will be changes on the branch that may be required
by uses who are currently using Xalan 1.0.1 with Xerces 1.0.3.  No actual
release on this branch is planned at this time.

*  Xalan/J 1.1.0 will be the release for compatibility to Xerces 1.0.4, and
will be on the main branch.  We are currently evaluating several additional
(priority 1) bug fixes that may go into this build.

* Xalan/J 2.0.0 will be what I was formerly calling Xalan/J 1.1.x.  This is
a pretty major rearchitecture, based on the TRaX APIs (trax.openxml.org),
with a data-driven build of the internal stylesheet, clean separation of
stylesheet data structures from runtime code, much cleaned up
transformation code, incremental SAX2-driven transformations with
structured indexing for scalability, general reorganization of flattening
of directory hierarchy, etc.  We feel this will be a major improvement to
the existing Xalan code base, and will be much more accessible to open
source developers.  We're hoping to post this publically soon... but it's
looking like it will still be a couple of weeks.  This will probably be put
into a new repository, or else we will put it in the xml-xalan/java/src
directory (like Xerces), the point being that it will not go on top of the
1.x.x base, because of the severity of the changes.

We think this is a good and reasonable plan of action.  Please let us know
if you have objections.

-scott

Re: Release number change of plans for Xalan - incremental part

[Lionel Villard <Li...@inrialpes.fr>]

What do you mean by incremental SAX2-driven transformations ? If it's the
incremental updating of the transformed
document after a source editing (probably, in your case, just add a node),
it's a hard task. I did some works about it
(currently i can do it on a subset of xslt). If you plan to do it in a
couple of week, i think it's a short time... But perhaps
you have already done some works on it ?


----- Original Message -----
From: Scott Boag/CAM/Lotus <Sc...@lotus.com>
To: <xa...@xml.apache.org>; <ge...@xml.apache.org>
Sent: Tuesday, May 16, 2000 12:03 AM
Subject: Release number change of plans for Xalan


> As most of you know, Xalan 1.0.1 turns out to be not compatible with the
> recently released Xerces 1.0.4, which has stirred the pot a bit for our
> next release plans.
>
> For background, here is how we define our release numbers:
>
> =============
> Xalan releases will use the notation Xalan/i v.r.x
>
> The values of i, v,r, and x had the following meanings:
>
> i is the implementation, either J for Java, or C for C/C++.
>
> v is the version number. The version number will change only when there is
> a significant, externally apparent enhancement from the previous version.
>
> r is the release number. The release number will change when a new set of
> functionality is to be added, e.g., implementation of a W3C specification.
> Release changes also typically indicate an API or behavior change.  [It's
> my assertion here that a change in external dependency should also require
> an upgrade in release number.]
>
> x is a drop number indicating a change to the release.  A drop number can
> be either [Dxx] defining a Development release representing progress
> towards completing a release(r); or [.xx] defining a maintenance drop for
a
> release(r).
> =============
>
> I'm not sure how closely we really have stuck to the exact letter of these
> definitions in the past, but that is the idea.
>
> Because an upgrade to Xalan to match Xerces 1.0.4 will *require* you to
> upgrade to Xerces 1.0.4, we feel we should upgrade the release number.
> Also, Xalan 1.1.x is turning out to be a much greater change that we
> originally anticipated.  Therefore, we feel we should schedule the
> following releases thus:
>
> *  Xalan/J 1.0.2, etc., will be changes on the branch that may be required
> by uses who are currently using Xalan 1.0.1 with Xerces 1.0.3.  No actual
> release on this branch is planned at this time.
>
> *  Xalan/J 1.1.0 will be the release for compatibility to Xerces 1.0.4,
and
> will be on the main branch.  We are currently evaluating several
additional
> (priority 1) bug fixes that may go into this build.
>
> * Xalan/J 2.0.0 will be what I was formerly calling Xalan/J 1.1.x.  This
is
> a pretty major rearchitecture, based on the TRaX APIs (trax.openxml.org),
> with a data-driven build of the internal stylesheet, clean separation of
> stylesheet data structures from runtime code, much cleaned up
> transformation code, incremental SAX2-driven transformations with
> structured indexing for scalability, general reorganization of flattening
> of directory hierarchy, etc.  We feel this will be a major improvement to
> the existing Xalan code base, and will be much more accessible to open
> source developers.  We're hoping to post this publically soon... but it's
> looking like it will still be a couple of weeks.  This will probably be
put
> into a new repository, or else we will put it in the xml-xalan/java/src
> directory (like Xerces), the point being that it will not go on top of the
> 1.x.x base, because of the severity of the changes.
>
> We think this is a good and reasonable plan of action.  Please let us know
> if you have objections.
>
> -scott
>
>
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>