You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@bea.com> on 2006/08/05 18:58:41 UTC
version numbers
Hi,
Some questions about version numbers:
1. Is it true that we should keep the OpenJPA version number below 1.0
until we get out of incubation?
2. The @since tags in the OpenJPA javadocs are currently all relative to
Kodo version numbers (i.e., the most recent ones say @since 4.1, etc.).
How do we want to rectify this? Options:
a) Move OpenJPA's version number up to 4.1 as soon as it comes out of
incubation.
b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1 becomes
1.4.1.
c) Ignore the problem. There's nothing to see here.
d) Remove all the @since tags, and start afresh.
3. Should we be striving to keep the version numbers of the various
sub-modules in sync, or should each get a separate version number moving
forward?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: version numbers
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/5/06, Patrick Linskey <pl...@bea.com> wrote:
> Hi,
>
> Some questions about version numbers:
>
> 1. Is it true that we should keep the OpenJPA version number below 1.0
> until we get out of incubation?
projects under incubation are not allowed to create official apache
releases. the version number strategy is up to the project community.
IMHO there are a few reasons why most podlings choose to adopt this
version numbering model:
a 1.0 release is a good way to generate momentum for a project
especially amongst users. graduation followed soon by a good 1.0
release works well. the product and the community should be ready
after graduation to handle additional interest in a positive manner.
too much adoption too early can hurt a project's development. during
graduation, the ratio of active developers (in the apache sense of
http://incubator.apache.org/guides/participation.html#developer) to
passive users needs to be high. releasing 0.x versions is a way of
targetting active early adopters.
- robert
Re: version numbers
Posted by Abe White <aw...@bea.com>.
> Marc Prud'hommeaux proposed an interesting alternate to solution 2b
> -- we
> could prefix all the current @since tags with '0.', so that the old
> Kodo
> version information is still accessible (i.e., we'd have @since
> 0.3.3 for
> things that were introduced in Kodo 3.3).
+1
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
RE: version numbers
Posted by Patrick Linskey <pl...@bea.com>.
Ok, I just checked in an update that changes all of them (except for the
ones in the repackage util.concurrent package).
> I admire the discipline it took to put all those tags in
> there in the
> first place.
Thanks! Sadly, they're not 100% -- we certainly have added important
APIs without adding @since tags. Also, we typically have only added
@since for methods / classes that we expect will be used outside of
their immediate environment.
> I hope that's a tradition that continues.
Ditto.
-Patrick
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: version numbers
Posted by David Blevins <da...@visi.com>.
On Aug 29, 2006, at 6:01 PM, Patrick Linskey wrote:
> Does anyone have any thoughts about the questions posed below? In
> particular, I haven't heard a peep about issues > 1.
>
> Marc Prud'hommeaux proposed an interesting alternate to solution 2b
> -- we
> could prefix all the current @since tags with '0.', so that the old
> Kodo
> version information is still accessible (i.e., we'd have @since
> 0.3.3 for
> things that were introduced in Kodo 3.3).
>
> Thoughts?
>
Actually, I noticed this say two weeks back and was going to post
about it (wasn't subscribed when this was mentioned).
I like the '0.' solution. The @since tags are cool. Whether or not
it's Kodo specific, it's still valuable information on how the code
evolved -- a little window into OpenJPA before it's life at Apache.
It'd be a shame to remove it.
I admire the discipline it took to put all those tags in there in the
first place. I hope that's a tradition that continues.
-David
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
>> -----Original Message-----
>> From: Patrick Linskey
>> Sent: Saturday, August 05, 2006 9:59 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: version numbers
>>
>> Hi,
>>
>> Some questions about version numbers:
>>
>> 1. Is it true that we should keep the OpenJPA version number below
>> 1.0
>> until we get out of incubation?
>>
>>
>> 2. The @since tags in the OpenJPA javadocs are currently all
>> relative to
>> Kodo version numbers (i.e., the most recent ones say @since
>> 4.1, etc.).
>> How do we want to rectify this? Options:
>>
>> a) Move OpenJPA's version number up to 4.1 as soon as it comes out of
>> incubation.
>>
>> b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1
>> becomes
>> 1.4.1.
>>
>> c) Ignore the problem. There's nothing to see here.
>>
>> d) Remove all the @since tags, and start afresh.
>>
>>
>> 3. Should we be striving to keep the version numbers of the various
>> sub-modules in sync, or should each get a separate version
>> number moving
>> forward?
>>
>> -Patrick
>>
>> --
>> Patrick Linskey
>> BEA Systems, Inc.
>> ______________________________________________________________
>> _________
>> Notice: This email message, together with any attachments,
>> may contain
>> information of BEA Systems, Inc., its subsidiaries and
>> affiliated
>> entities, that may be confidential, proprietary,
>> copyrighted and/or
>> legally privileged, and is intended solely for the use of the
>> individual
>> or entity named in this message. If you are not the intended
>> recipient,
>> and have received this message in error, please immediately
>> return this
>> by email and then delete it.
>>
> ______________________________________________________________________
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
Re: version numbers
Posted by Kevin Sutter <kw...@gmail.com>.
+1 for the 0. prefix. Keeping the old Kodo history might be helpful for you
in the future.
I also think that keeping all of the sub-projects' version numbers in synch
makes the most sense.
Kevin
On 8/30/06, Craig L Russell <Cr...@sun.com> wrote:
>
> +1 on prepending 0. to the current version numbers.
>
> More below.
>
> On Aug 29, 2006, at 9:35 PM, Pinaki Poddar wrote:
>
> > Neat idea.
> > +1.
> >
> >
> > Pinaki Poddar
> > BEA Systems
> > 415.402.7317
> >
> >
> > -----Original Message-----
> > From: Patrick Linskey
> > Sent: Tuesday, August 29, 2006 6:01 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: RE: version numbers
> >
> > Does anyone have any thoughts about the questions posed below? In
> > particular, I haven't heard a peep about issues > 1.
> >
> > Marc Prud'hommeaux proposed an interesting alternate to solution 2b --
> > we could prefix all the current @since tags with '0.', so that the old
> > Kodo version information is still accessible (i.e., we'd have @since
> > 0.3.3 for things that were introduced in Kodo 3.3).
> >
> > Thoughts?
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> >> -----Original Message-----
> >> From: Patrick Linskey
> >> Sent: Saturday, August 05, 2006 9:59 AM
> >> To: open-jpa-dev@incubator.apache.org
> >> Subject: version numbers
> >>
> >> Hi,
> >>
> >> Some questions about version numbers:
> >>
> >> 1. Is it true that we should keep the OpenJPA version number below
> >> 1.0
> >
> >> until we get out of incubation?
>
> I don't think it matters at all. We can cut a release in the
> incubator or wait until after graduation. I wouldn't tie the version
> number to whether we're still in incubation or not.
> >>
> >>
> >> 2. The @since tags in the OpenJPA javadocs are currently all relative
> >> to Kodo version numbers (i.e., the most recent ones say @since 4.1,
> >> etc.).
> >> How do we want to rectify this? Options:
> >>
> >> a) Move OpenJPA's version number up to 4.1 as soon as it comes out of
> >> incubation.
> >>
> >> b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1
> >> becomes
> >
> >> 1.4.1.
> >>
> >> c) Ignore the problem. There's nothing to see here.
> >>
> >> d) Remove all the @since tags, and start afresh.
> >>
> >>
> >> 3. Should we be striving to keep the version numbers of the various
> >> sub-modules in sync, or should each get a separate version number
> >> moving forward?
>
> I'd think keeping them in sync makes the most sense. I don't get the
> idea that the components are completely independent of each other. If
> you make a change in a kernel interface, all other components that
> use that interface need to change. So for me all the modules should
> get the same version.
>
> Craig
>
> >>
> >> -Patrick
> >>
> >> --
> >> Patrick Linskey
> >> BEA Systems, Inc.
> >> ______________________________________________________________
> >> _________
> >> Notice: This email message, together with any attachments, may
> >> contain information of BEA Systems, Inc., its subsidiaries and
> >> affiliated entities, that may be confidential, proprietary,
> >> copyrighted and/or legally privileged, and is intended solely for
> >> the
> >
> >> use of the individual or entity named in this message. If you are not
> >> the intended recipient, and have received this message in error,
> >> please immediately return this by email and then delete it.
> >>
> > ______________________________________________________________________
> > _
> > Notice: This email message, together with any attachments, may
> > contain
> > information of BEA Systems, Inc., its subsidiaries and
> > affiliated
> > entities, that may be confidential, proprietary, copyrighted
> > and/or
> > legally privileged, and is intended solely for the use of the
> > individual
> > or entity named in this message. If you are not the intended
> > recipient,
> > and have received this message in error, please immediately return
> > this
> > by email and then delete it.
>
> Craig Russell
> clr@apache.org http://db.apache.org/jdo
>
>
>
>
>
Re: version numbers
Posted by Craig L Russell <Cr...@Sun.COM>.
+1 on prepending 0. to the current version numbers.
More below.
On Aug 29, 2006, at 9:35 PM, Pinaki Poddar wrote:
> Neat idea.
> +1.
>
>
> Pinaki Poddar
> BEA Systems
> 415.402.7317
>
>
> -----Original Message-----
> From: Patrick Linskey
> Sent: Tuesday, August 29, 2006 6:01 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: version numbers
>
> Does anyone have any thoughts about the questions posed below? In
> particular, I haven't heard a peep about issues > 1.
>
> Marc Prud'hommeaux proposed an interesting alternate to solution 2b --
> we could prefix all the current @since tags with '0.', so that the old
> Kodo version information is still accessible (i.e., we'd have @since
> 0.3.3 for things that were introduced in Kodo 3.3).
>
> Thoughts?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
>> -----Original Message-----
>> From: Patrick Linskey
>> Sent: Saturday, August 05, 2006 9:59 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: version numbers
>>
>> Hi,
>>
>> Some questions about version numbers:
>>
>> 1. Is it true that we should keep the OpenJPA version number below
>> 1.0
>
>> until we get out of incubation?
I don't think it matters at all. We can cut a release in the
incubator or wait until after graduation. I wouldn't tie the version
number to whether we're still in incubation or not.
>>
>>
>> 2. The @since tags in the OpenJPA javadocs are currently all relative
>> to Kodo version numbers (i.e., the most recent ones say @since 4.1,
>> etc.).
>> How do we want to rectify this? Options:
>>
>> a) Move OpenJPA's version number up to 4.1 as soon as it comes out of
>> incubation.
>>
>> b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1
>> becomes
>
>> 1.4.1.
>>
>> c) Ignore the problem. There's nothing to see here.
>>
>> d) Remove all the @since tags, and start afresh.
>>
>>
>> 3. Should we be striving to keep the version numbers of the various
>> sub-modules in sync, or should each get a separate version number
>> moving forward?
I'd think keeping them in sync makes the most sense. I don't get the
idea that the components are completely independent of each other. If
you make a change in a kernel interface, all other components that
use that interface need to change. So for me all the modules should
get the same version.
Craig
>>
>> -Patrick
>>
>> --
>> Patrick Linskey
>> BEA Systems, Inc.
>> ______________________________________________________________
>> _________
>> Notice: This email message, together with any attachments, may
>> contain information of BEA Systems, Inc., its subsidiaries and
>> affiliated entities, that may be confidential, proprietary,
>> copyrighted and/or legally privileged, and is intended solely for
>> the
>
>> use of the individual or entity named in this message. If you are not
>> the intended recipient, and have received this message in error,
>> please immediately return this by email and then delete it.
>>
> ______________________________________________________________________
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
Craig Russell
clr@apache.org http://db.apache.org/jdo
RE: version numbers
Posted by Pinaki Poddar <pp...@bea.com>.
Neat idea.
+1.
Pinaki Poddar
BEA Systems
415.402.7317
-----Original Message-----
From: Patrick Linskey
Sent: Tuesday, August 29, 2006 6:01 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: version numbers
Does anyone have any thoughts about the questions posed below? In
particular, I haven't heard a peep about issues > 1.
Marc Prud'hommeaux proposed an interesting alternate to solution 2b --
we could prefix all the current @since tags with '0.', so that the old
Kodo version information is still accessible (i.e., we'd have @since
0.3.3 for things that were introduced in Kodo 3.3).
Thoughts?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
> -----Original Message-----
> From: Patrick Linskey
> Sent: Saturday, August 05, 2006 9:59 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: version numbers
>
> Hi,
>
> Some questions about version numbers:
>
> 1. Is it true that we should keep the OpenJPA version number below 1.0
> until we get out of incubation?
>
>
> 2. The @since tags in the OpenJPA javadocs are currently all relative
> to Kodo version numbers (i.e., the most recent ones say @since 4.1,
> etc.).
> How do we want to rectify this? Options:
>
> a) Move OpenJPA's version number up to 4.1 as soon as it comes out of
> incubation.
>
> b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1 becomes
> 1.4.1.
>
> c) Ignore the problem. There's nothing to see here.
>
> d) Remove all the @since tags, and start afresh.
>
>
> 3. Should we be striving to keep the version numbers of the various
> sub-modules in sync, or should each get a separate version number
> moving forward?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
> ______________________________________________________________
> _________
> Notice: This email message, together with any attachments, may
> contain information of BEA Systems, Inc., its subsidiaries and
> affiliated entities, that may be confidential, proprietary,
> copyrighted and/or legally privileged, and is intended solely for the
> use of the individual or entity named in this message. If you are not
> the intended recipient, and have received this message in error,
> please immediately return this by email and then delete it.
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
RE: version numbers
Posted by Patrick Linskey <pl...@bea.com>.
Does anyone have any thoughts about the questions posed below? In
particular, I haven't heard a peep about issues > 1.
Marc Prud'hommeaux proposed an interesting alternate to solution 2b -- we
could prefix all the current @since tags with '0.', so that the old Kodo
version information is still accessible (i.e., we'd have @since 0.3.3 for
things that were introduced in Kodo 3.3).
Thoughts?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
> -----Original Message-----
> From: Patrick Linskey
> Sent: Saturday, August 05, 2006 9:59 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: version numbers
>
> Hi,
>
> Some questions about version numbers:
>
> 1. Is it true that we should keep the OpenJPA version number below 1.0
> until we get out of incubation?
>
>
> 2. The @since tags in the OpenJPA javadocs are currently all
> relative to
> Kodo version numbers (i.e., the most recent ones say @since
> 4.1, etc.).
> How do we want to rectify this? Options:
>
> a) Move OpenJPA's version number up to 4.1 as soon as it comes out of
> incubation.
>
> b) The Reverse Emacs. Toss a 1 onto the beginning, so that 4.1 becomes
> 1.4.1.
>
> c) Ignore the problem. There's nothing to see here.
>
> d) Remove all the @since tags, and start afresh.
>
>
> 3. Should we be striving to keep the version numbers of the various
> sub-modules in sync, or should each get a separate version
> number moving
> forward?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
> ______________________________________________________________
> _________
> Notice: This email message, together with any attachments,
> may contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary,
> copyrighted and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately
> return this
> by email and then delete it.
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.