merging to 1.0.x

[Patrick Linskey <pl...@gmail.com>]

Hi,

It seems like we've had a lot of activity merging things to the 1.0.x
branch. Personally, it seems like there's maybe even too much stuff
going into there; what is our plan for QA for the changes in the 1.0.1
release at this point?

Also, a lot of the @since tags are now wrong, since they were written
with 1.1.0 in mind, but now the changes are slated for 1.0.1.

Thoughts?

-Patrick

-- 
Patrick Linskey
202 669 5907

Re: merging to 1.0.x

[Patrick Linskey <pl...@gmail.com>]

That's the type of thing that would not hold me back from putting a
patch into a patch line, I think, if I thought the patch were
important enough. Which, clearly, I didn't in this case, since I
didn't merge it over in the first place.

BTW, I'm assuming that you've discovered the 'svn merge -c' syntax; it
makes moving changes from trunk to src pretty painless.

-Patrick

On 9/20/07, Michael Dick <mi...@gmail.com> wrote:
> I'm not sure the Select interface is entirely internal. It's not a user
> facing API by any means, but if you're extending the OpenJPA provider, you
> might need to use the interface.
>
> If a third party persistence provider has a custom SQLFactory class they
> might also have a custom SelectImpl. If the custom SelectImpl doesn't extend
> our classes then they'll have to update their code to account for the new
> method.
>
> There are a lot of ifs here, and I'm not aware of anyone that fits my
> scenario. Maybe it's a corner case though.
>
> -Mike
>
> On 9/20/07, Patrick Linskey <pl...@gmail.com> wrote:
> >
> > > Actually on further inspection I think I messed up when I merged
> > > OPENJPA-356. I didn't notice that I updated the Select interface which
> > > shouldn't be done on a maintenance release. I checked with Kevin and he
> > > agreed, so I've backed out the change. Sorry for making a mess in svn.
> >
> > I'd say that that's definitely a fair change. It's just an added
> > method, which won't cause any compile problems. Additionally, that
> > class is very much an internal part of OpenJPA; what level of
> > compatibility within a patch release do we want to guarantee for
> > internals?
> >
> > Ideally, it seems like it'd be nice to keep our API stable pretty much
> > forever, and then have some internal SPIs that have a lower level of
> > compatibility promises.
> >
> > -Patrick
> >
> > On 9/19/07, Michael Dick <mi...@gmail.com> wrote:
> > > Actually on further inspection I think I messed up when I merged
> > > OPENJPA-356. I didn't notice that I updated the Select interface which
> > > shouldn't be done on a maintenance release. I checked with Kevin and he
> > > agreed, so I've backed out the change. Sorry for making a mess in svn.
> > >
> > > General comments below (for what they're worth)
> > >
> > > On 9/19/07, Patrick Linskey <pl...@gmail.com> wrote:
> > > >
> > > > I don't think that you are misinterpreting it. Also, I don't think
> > > > that we've done anything that's bad yet; I just thought it'd be good
> > > > to discuss to make sure we're all on the same page.
> > > >
> > > > Personally, I do not much like the idea of porting all of my changes
> > > > to multiple branches every time I change something. That definitely
> > > > discourages me from making fixes.
> > >
> > >
> > > Perfectly fine by me. Any bug fixes should be fair game to be merged
> > later
> > > though. Conversations like this will come up if any of us get over
> > zealous
> > > and move something they shouldn't have
> > >
> > > During the release process, we decided that it was not the
> > > > responsibility of the release builder to merge changes made in an
> > > > x.y.z branch back to the trunk. I think that where we arrived was that
> > > > it should instead be the responsibility of the developers to get the
> > > > code to wherever they deemed it belonged, under the assumption that
> > > > the x.y.z branches would never pick up changes or merge back down in a
> > > > bulk / automated manner.
> > >
> > >
> > > > For example, I've made some fixes that I thought were important enough
> > > > to do the svn merge to the branch, and I've made some that I didn't
> > > > think were really that important. You may have subsequently moved some
> > > > of those to the branch (I haven't checked that closely); that's great,
> > > > since presumably you thought that the changes were important enough to
> > > > spend the time on.
> > > >
> > > > To sum up, I think it's important that we not destabilize the
> > > > branches, but other than that, we should feel free, but not obligated,
> > > > to put fixes into trunk and relevant branches. But we must remember
> > > > that there is no process in place to move changes only made in a
> > > > branch back to the trunk.
> > >
> > >
> > > I think I agree. The main point here is that there's no automatic
> > merging
> > > going on. It's up to individual committers to put their fixes in the
> > > appropriate branches etc.
> > >
> > >
> > > -Patrick
> > > >
> > > > On 9/19/07, Kevin Sutter <kw...@gmail.com> wrote:
> > > > > Hi Patrick,
> > > > > It seemed like a lot of "fixes" were going into the 1.1.0 release
> > and
> > > > not
> > > > > making it back into the 1.0.x release.  Since it seemed like it
> > might be
> > > > a
> > > > > while before we develop enough new feature content to warrant a bump
> > > > from
> > > > > 1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.xup-to-date
> > > > as
> > > > > far as fixes are concerned.  I had done a quick JIRA query and found
> > > > that we
> > > > > had close to a dozen fixes in the 1.1.0 release that had not made it
> > > > back to
> > > > > the 1.0.x release.  Reading through the JIRA reports, the problems
> > > > sounded
> > > > > like plain old defects and not new features.  I started to move some
> > of
> > > > the
> > > > > changes back to the 1.0.x release and then Mike started to help out.
> > > > >
> > > > > So, from a release maintenance viewpoint, I would like us to be more
> > > > > diligent with ensuring that defect fixes make it back into the
> > current
> > > > > maintenance release (as well as trunk).  Of course, there may be
> > reasons
> > > > why
> > > > > this may not make sense due to the extent of the changes, but so far
> > the
> > > > > changes have been pretty minimal.  The most extensive change is with
> > the
> > > > > Java 2 security changes at this point.
> > > > >
> > > > > If I am misinterpreting the x.y.z release conventions, then let's
> > > > discuss
> > > > > that.
> > > > >
> > > > > Thanks,
> > > > > Kevin
> > > > >
> > > > > On 9/18/07, Patrick Linskey <pl...@gmail.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > It seems like we've had a lot of activity merging things to the
> > 1.0.x
> > > > > > branch. Personally, it seems like there's maybe even too much
> > stuff
> > > > > > going into there; what is our plan for QA for the changes in the
> > 1.0.1
> > > > > > release at this point?
> > > > > >
> > > > > > Also, a lot of the @since tags are now wrong, since they were
> > written
> > > > > > with 1.1.0 in mind, but now the changes are slated for 1.0.1.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > -Patrick
> > > > > >
> > > > > > --
> > > > > > Patrick Linskey
> > > > > > 202 669 5907
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Patrick Linskey
> > > > 202 669 5907
> > > >
> > >
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
>


-- 
Patrick Linskey
202 669 5907

Re: merging to 1.0.x

[Michael Dick <mi...@gmail.com>]

I'm not sure the Select interface is entirely internal. It's not a user
facing API by any means, but if you're extending the OpenJPA provider, you
might need to use the interface.

If a third party persistence provider has a custom SQLFactory class they
might also have a custom SelectImpl. If the custom SelectImpl doesn't extend
our classes then they'll have to update their code to account for the new
method.

There are a lot of ifs here, and I'm not aware of anyone that fits my
scenario. Maybe it's a corner case though.

-Mike

On 9/20/07, Patrick Linskey <pl...@gmail.com> wrote:
>
> > Actually on further inspection I think I messed up when I merged
> > OPENJPA-356. I didn't notice that I updated the Select interface which
> > shouldn't be done on a maintenance release. I checked with Kevin and he
> > agreed, so I've backed out the change. Sorry for making a mess in svn.
>
> I'd say that that's definitely a fair change. It's just an added
> method, which won't cause any compile problems. Additionally, that
> class is very much an internal part of OpenJPA; what level of
> compatibility within a patch release do we want to guarantee for
> internals?
>
> Ideally, it seems like it'd be nice to keep our API stable pretty much
> forever, and then have some internal SPIs that have a lower level of
> compatibility promises.
>
> -Patrick
>
> On 9/19/07, Michael Dick <mi...@gmail.com> wrote:
> > Actually on further inspection I think I messed up when I merged
> > OPENJPA-356. I didn't notice that I updated the Select interface which
> > shouldn't be done on a maintenance release. I checked with Kevin and he
> > agreed, so I've backed out the change. Sorry for making a mess in svn.
> >
> > General comments below (for what they're worth)
> >
> > On 9/19/07, Patrick Linskey <pl...@gmail.com> wrote:
> > >
> > > I don't think that you are misinterpreting it. Also, I don't think
> > > that we've done anything that's bad yet; I just thought it'd be good
> > > to discuss to make sure we're all on the same page.
> > >
> > > Personally, I do not much like the idea of porting all of my changes
> > > to multiple branches every time I change something. That definitely
> > > discourages me from making fixes.
> >
> >
> > Perfectly fine by me. Any bug fixes should be fair game to be merged
> later
> > though. Conversations like this will come up if any of us get over
> zealous
> > and move something they shouldn't have
> >
> > During the release process, we decided that it was not the
> > > responsibility of the release builder to merge changes made in an
> > > x.y.z branch back to the trunk. I think that where we arrived was that
> > > it should instead be the responsibility of the developers to get the
> > > code to wherever they deemed it belonged, under the assumption that
> > > the x.y.z branches would never pick up changes or merge back down in a
> > > bulk / automated manner.
> >
> >
> > > For example, I've made some fixes that I thought were important enough
> > > to do the svn merge to the branch, and I've made some that I didn't
> > > think were really that important. You may have subsequently moved some
> > > of those to the branch (I haven't checked that closely); that's great,
> > > since presumably you thought that the changes were important enough to
> > > spend the time on.
> > >
> > > To sum up, I think it's important that we not destabilize the
> > > branches, but other than that, we should feel free, but not obligated,
> > > to put fixes into trunk and relevant branches. But we must remember
> > > that there is no process in place to move changes only made in a
> > > branch back to the trunk.
> >
> >
> > I think I agree. The main point here is that there's no automatic
> merging
> > going on. It's up to individual committers to put their fixes in the
> > appropriate branches etc.
> >
> >
> > -Patrick
> > >
> > > On 9/19/07, Kevin Sutter <kw...@gmail.com> wrote:
> > > > Hi Patrick,
> > > > It seemed like a lot of "fixes" were going into the 1.1.0 release
> and
> > > not
> > > > making it back into the 1.0.x release.  Since it seemed like it
> might be
> > > a
> > > > while before we develop enough new feature content to warrant a bump
> > > from
> > > > 1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.xup-to-date
> > > as
> > > > far as fixes are concerned.  I had done a quick JIRA query and found
> > > that we
> > > > had close to a dozen fixes in the 1.1.0 release that had not made it
> > > back to
> > > > the 1.0.x release.  Reading through the JIRA reports, the problems
> > > sounded
> > > > like plain old defects and not new features.  I started to move some
> of
> > > the
> > > > changes back to the 1.0.x release and then Mike started to help out.
> > > >
> > > > So, from a release maintenance viewpoint, I would like us to be more
> > > > diligent with ensuring that defect fixes make it back into the
> current
> > > > maintenance release (as well as trunk).  Of course, there may be
> reasons
> > > why
> > > > this may not make sense due to the extent of the changes, but so far
> the
> > > > changes have been pretty minimal.  The most extensive change is with
> the
> > > > Java 2 security changes at this point.
> > > >
> > > > If I am misinterpreting the x.y.z release conventions, then let's
> > > discuss
> > > > that.
> > > >
> > > > Thanks,
> > > > Kevin
> > > >
> > > > On 9/18/07, Patrick Linskey <pl...@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > It seems like we've had a lot of activity merging things to the
> 1.0.x
> > > > > branch. Personally, it seems like there's maybe even too much
> stuff
> > > > > going into there; what is our plan for QA for the changes in the
> 1.0.1
> > > > > release at this point?
> > > > >
> > > > > Also, a lot of the @since tags are now wrong, since they were
> written
> > > > > with 1.1.0 in mind, but now the changes are slated for 1.0.1.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Patrick
> > > > >
> > > > > --
> > > > > Patrick Linskey
> > > > > 202 669 5907
> > > > >
> > > >
> > >
> > >
> > > --
> > > Patrick Linskey
> > > 202 669 5907
> > >
> >
>
>
> --
> Patrick Linskey
> 202 669 5907
>

Re: merging to 1.0.x

[Patrick Linskey <pl...@gmail.com>]

> Actually on further inspection I think I messed up when I merged
> OPENJPA-356. I didn't notice that I updated the Select interface which
> shouldn't be done on a maintenance release. I checked with Kevin and he
> agreed, so I've backed out the change. Sorry for making a mess in svn.

I'd say that that's definitely a fair change. It's just an added
method, which won't cause any compile problems. Additionally, that
class is very much an internal part of OpenJPA; what level of
compatibility within a patch release do we want to guarantee for
internals?

Ideally, it seems like it'd be nice to keep our API stable pretty much
forever, and then have some internal SPIs that have a lower level of
compatibility promises.

-Patrick

On 9/19/07, Michael Dick <mi...@gmail.com> wrote:
> Actually on further inspection I think I messed up when I merged
> OPENJPA-356. I didn't notice that I updated the Select interface which
> shouldn't be done on a maintenance release. I checked with Kevin and he
> agreed, so I've backed out the change. Sorry for making a mess in svn.
>
> General comments below (for what they're worth)
>
> On 9/19/07, Patrick Linskey <pl...@gmail.com> wrote:
> >
> > I don't think that you are misinterpreting it. Also, I don't think
> > that we've done anything that's bad yet; I just thought it'd be good
> > to discuss to make sure we're all on the same page.
> >
> > Personally, I do not much like the idea of porting all of my changes
> > to multiple branches every time I change something. That definitely
> > discourages me from making fixes.
>
>
> Perfectly fine by me. Any bug fixes should be fair game to be merged later
> though. Conversations like this will come up if any of us get over zealous
> and move something they shouldn't have
>
> During the release process, we decided that it was not the
> > responsibility of the release builder to merge changes made in an
> > x.y.z branch back to the trunk. I think that where we arrived was that
> > it should instead be the responsibility of the developers to get the
> > code to wherever they deemed it belonged, under the assumption that
> > the x.y.z branches would never pick up changes or merge back down in a
> > bulk / automated manner.
>
>
> > For example, I've made some fixes that I thought were important enough
> > to do the svn merge to the branch, and I've made some that I didn't
> > think were really that important. You may have subsequently moved some
> > of those to the branch (I haven't checked that closely); that's great,
> > since presumably you thought that the changes were important enough to
> > spend the time on.
> >
> > To sum up, I think it's important that we not destabilize the
> > branches, but other than that, we should feel free, but not obligated,
> > to put fixes into trunk and relevant branches. But we must remember
> > that there is no process in place to move changes only made in a
> > branch back to the trunk.
>
>
> I think I agree. The main point here is that there's no automatic merging
> going on. It's up to individual committers to put their fixes in the
> appropriate branches etc.
>
>
> -Patrick
> >
> > On 9/19/07, Kevin Sutter <kw...@gmail.com> wrote:
> > > Hi Patrick,
> > > It seemed like a lot of "fixes" were going into the 1.1.0 release and
> > not
> > > making it back into the 1.0.x release.  Since it seemed like it might be
> > a
> > > while before we develop enough new feature content to warrant a bump
> > from
> > > 1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.x up-to-date
> > as
> > > far as fixes are concerned.  I had done a quick JIRA query and found
> > that we
> > > had close to a dozen fixes in the 1.1.0 release that had not made it
> > back to
> > > the 1.0.x release.  Reading through the JIRA reports, the problems
> > sounded
> > > like plain old defects and not new features.  I started to move some of
> > the
> > > changes back to the 1.0.x release and then Mike started to help out.
> > >
> > > So, from a release maintenance viewpoint, I would like us to be more
> > > diligent with ensuring that defect fixes make it back into the current
> > > maintenance release (as well as trunk).  Of course, there may be reasons
> > why
> > > this may not make sense due to the extent of the changes, but so far the
> > > changes have been pretty minimal.  The most extensive change is with the
> > > Java 2 security changes at this point.
> > >
> > > If I am misinterpreting the x.y.z release conventions, then let's
> > discuss
> > > that.
> > >
> > > Thanks,
> > > Kevin
> > >
> > > On 9/18/07, Patrick Linskey <pl...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > It seems like we've had a lot of activity merging things to the 1.0.x
> > > > branch. Personally, it seems like there's maybe even too much stuff
> > > > going into there; what is our plan for QA for the changes in the 1.0.1
> > > > release at this point?
> > > >
> > > > Also, a lot of the @since tags are now wrong, since they were written
> > > > with 1.1.0 in mind, but now the changes are slated for 1.0.1.
> > > >
> > > > Thoughts?
> > > >
> > > > -Patrick
> > > >
> > > > --
> > > > Patrick Linskey
> > > > 202 669 5907
> > > >
> > >
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
>


-- 
Patrick Linskey
202 669 5907

Re: merging to 1.0.x

[Michael Dick <mi...@gmail.com>]

Actually on further inspection I think I messed up when I merged
OPENJPA-356. I didn't notice that I updated the Select interface which
shouldn't be done on a maintenance release. I checked with Kevin and he
agreed, so I've backed out the change. Sorry for making a mess in svn.

General comments below (for what they're worth)

On 9/19/07, Patrick Linskey <pl...@gmail.com> wrote:
>
> I don't think that you are misinterpreting it. Also, I don't think
> that we've done anything that's bad yet; I just thought it'd be good
> to discuss to make sure we're all on the same page.
>
> Personally, I do not much like the idea of porting all of my changes
> to multiple branches every time I change something. That definitely
> discourages me from making fixes.


Perfectly fine by me. Any bug fixes should be fair game to be merged later
though. Conversations like this will come up if any of us get over zealous
and move something they shouldn't have

During the release process, we decided that it was not the
> responsibility of the release builder to merge changes made in an
> x.y.z branch back to the trunk. I think that where we arrived was that
> it should instead be the responsibility of the developers to get the
> code to wherever they deemed it belonged, under the assumption that
> the x.y.z branches would never pick up changes or merge back down in a
> bulk / automated manner.


> For example, I've made some fixes that I thought were important enough
> to do the svn merge to the branch, and I've made some that I didn't
> think were really that important. You may have subsequently moved some
> of those to the branch (I haven't checked that closely); that's great,
> since presumably you thought that the changes were important enough to
> spend the time on.
>
> To sum up, I think it's important that we not destabilize the
> branches, but other than that, we should feel free, but not obligated,
> to put fixes into trunk and relevant branches. But we must remember
> that there is no process in place to move changes only made in a
> branch back to the trunk.


I think I agree. The main point here is that there's no automatic merging
going on. It's up to individual committers to put their fixes in the
appropriate branches etc.


-Patrick
>
> On 9/19/07, Kevin Sutter <kw...@gmail.com> wrote:
> > Hi Patrick,
> > It seemed like a lot of "fixes" were going into the 1.1.0 release and
> not
> > making it back into the 1.0.x release.  Since it seemed like it might be
> a
> > while before we develop enough new feature content to warrant a bump
> from
> > 1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.x up-to-date
> as
> > far as fixes are concerned.  I had done a quick JIRA query and found
> that we
> > had close to a dozen fixes in the 1.1.0 release that had not made it
> back to
> > the 1.0.x release.  Reading through the JIRA reports, the problems
> sounded
> > like plain old defects and not new features.  I started to move some of
> the
> > changes back to the 1.0.x release and then Mike started to help out.
> >
> > So, from a release maintenance viewpoint, I would like us to be more
> > diligent with ensuring that defect fixes make it back into the current
> > maintenance release (as well as trunk).  Of course, there may be reasons
> why
> > this may not make sense due to the extent of the changes, but so far the
> > changes have been pretty minimal.  The most extensive change is with the
> > Java 2 security changes at this point.
> >
> > If I am misinterpreting the x.y.z release conventions, then let's
> discuss
> > that.
> >
> > Thanks,
> > Kevin
> >
> > On 9/18/07, Patrick Linskey <pl...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > It seems like we've had a lot of activity merging things to the 1.0.x
> > > branch. Personally, it seems like there's maybe even too much stuff
> > > going into there; what is our plan for QA for the changes in the 1.0.1
> > > release at this point?
> > >
> > > Also, a lot of the @since tags are now wrong, since they were written
> > > with 1.1.0 in mind, but now the changes are slated for 1.0.1.
> > >
> > > Thoughts?
> > >
> > > -Patrick
> > >
> > > --
> > > Patrick Linskey
> > > 202 669 5907
> > >
> >
>
>
> --
> Patrick Linskey
> 202 669 5907
>

Re: merging to 1.0.x

[Patrick Linskey <pl...@gmail.com>]

I don't think that you are misinterpreting it. Also, I don't think
that we've done anything that's bad yet; I just thought it'd be good
to discuss to make sure we're all on the same page.

Personally, I do not much like the idea of porting all of my changes
to multiple branches every time I change something. That definitely
discourages me from making fixes.

During the release process, we decided that it was not the
responsibility of the release builder to merge changes made in an
x.y.z branch back to the trunk. I think that where we arrived was that
it should instead be the responsibility of the developers to get the
code to wherever they deemed it belonged, under the assumption that
the x.y.z branches would never pick up changes or merge back down in a
bulk / automated manner.

For example, I've made some fixes that I thought were important enough
to do the svn merge to the branch, and I've made some that I didn't
think were really that important. You may have subsequently moved some
of those to the branch (I haven't checked that closely); that's great,
since presumably you thought that the changes were important enough to
spend the time on.

To sum up, I think it's important that we not destabilize the
branches, but other than that, we should feel free, but not obligated,
to put fixes into trunk and relevant branches. But we must remember
that there is no process in place to move changes only made in a
branch back to the trunk.

-Patrick

On 9/19/07, Kevin Sutter <kw...@gmail.com> wrote:
> Hi Patrick,
> It seemed like a lot of "fixes" were going into the 1.1.0 release and not
> making it back into the 1.0.x release.  Since it seemed like it might be a
> while before we develop enough new feature content to warrant a bump from
> 1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.x up-to-date as
> far as fixes are concerned.  I had done a quick JIRA query and found that we
> had close to a dozen fixes in the 1.1.0 release that had not made it back to
> the 1.0.x release.  Reading through the JIRA reports, the problems sounded
> like plain old defects and not new features.  I started to move some of the
> changes back to the 1.0.x release and then Mike started to help out.
>
> So, from a release maintenance viewpoint, I would like us to be more
> diligent with ensuring that defect fixes make it back into the current
> maintenance release (as well as trunk).  Of course, there may be reasons why
> this may not make sense due to the extent of the changes, but so far the
> changes have been pretty minimal.  The most extensive change is with the
> Java 2 security changes at this point.
>
> If I am misinterpreting the x.y.z release conventions, then let's discuss
> that.
>
> Thanks,
> Kevin
>
> On 9/18/07, Patrick Linskey <pl...@gmail.com> wrote:
> >
> > Hi,
> >
> > It seems like we've had a lot of activity merging things to the 1.0.x
> > branch. Personally, it seems like there's maybe even too much stuff
> > going into there; what is our plan for QA for the changes in the 1.0.1
> > release at this point?
> >
> > Also, a lot of the @since tags are now wrong, since they were written
> > with 1.1.0 in mind, but now the changes are slated for 1.0.1.
> >
> > Thoughts?
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
>


-- 
Patrick Linskey
202 669 5907

Re: merging to 1.0.x

[Kevin Sutter <kw...@gmail.com>]

Hi Patrick,
It seemed like a lot of "fixes" were going into the 1.1.0 release and not
making it back into the 1.0.x release.  Since it seemed like it might be a
while before we develop enough new feature content to warrant a bump from
1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.x up-to-date as
far as fixes are concerned.  I had done a quick JIRA query and found that we
had close to a dozen fixes in the 1.1.0 release that had not made it back to
the 1.0.x release.  Reading through the JIRA reports, the problems sounded
like plain old defects and not new features.  I started to move some of the
changes back to the 1.0.x release and then Mike started to help out.

So, from a release maintenance viewpoint, I would like us to be more
diligent with ensuring that defect fixes make it back into the current
maintenance release (as well as trunk).  Of course, there may be reasons why
this may not make sense due to the extent of the changes, but so far the
changes have been pretty minimal.  The most extensive change is with the
Java 2 security changes at this point.

If I am misinterpreting the x.y.z release conventions, then let's discuss
that.

Thanks,
Kevin

On 9/18/07, Patrick Linskey <pl...@gmail.com> wrote:
>
> Hi,
>
> It seems like we've had a lot of activity merging things to the 1.0.x
> branch. Personally, it seems like there's maybe even too much stuff
> going into there; what is our plan for QA for the changes in the 1.0.1
> release at this point?
>
> Also, a lot of the @since tags are now wrong, since they were written
> with 1.1.0 in mind, but now the changes are slated for 1.0.1.
>
> Thoughts?
>
> -Patrick
>
> --
> Patrick Linskey
> 202 669 5907
>