Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # general >> [DISCUSS] Apache Hadoop 1.0?


+
Arun C Murthy 2011-11-14, 22:11
+
Doug Cutting 2011-11-14, 22:41
+
Mattmann, Chris A 2011-11-14, 22:47
+
Todd Papaioannou 2011-11-14, 22:47
+
Milind.Bhandarkar@... 2011-11-14, 22:44
+
Mattmann, Chris A 2011-11-14, 22:46
+
Konstantin Boudnik 2011-11-14, 23:01
+
Sharad Agarwal 2011-11-15, 05:37
+
Mahadev Konar 2011-11-15, 06:23
+
Owen OMalley 2011-11-15, 05:47
+
Andreas Neumann 2011-11-15, 05:56
+
Owen OMalley 2011-11-15, 06:20
+
Dhruba Borthakur 2011-11-15, 06:07
+
Steve Loughran 2011-11-15, 09:57
+
Todd Lipcon 2011-11-15, 21:43
+
Owen OMalley 2011-11-15, 22:17
+
Ted Dunning 2011-11-15, 22:25
+
Arun C Murthy 2011-11-15, 22:32
+
Luke Lu 2011-11-15, 22:40
+
Doug Cutting 2011-11-16, 01:37
+
Ahmed Radwan 2011-11-16, 01:41
+
Eli Collins 2011-11-16, 01:49
+
Doug Cutting 2011-11-16, 01:56
+
Eli Collins 2011-11-16, 02:03
+
Arun Murthy 2011-11-16, 04:20
+
Matt Foley 2011-11-16, 02:42
+
Konstantin Boudnik 2011-11-16, 02:47
+
Joe Stein 2011-11-16, 03:35
+
Konstantin Shvachko 2011-11-16, 07:26
+
Konstantin Shvachko 2011-11-16, 15:46
+
Scott Carey 2011-11-16, 07:06
+
Arun Murthy 2011-11-16, 04:14
+
Eli Collins 2011-11-16, 04:51
+
Joe Stein 2011-11-16, 05:37
+
Arun Murthy 2011-11-16, 05:53
+
Eli Collins 2011-11-16, 06:13
+
Arun Murthy 2011-11-16, 07:05
+
Konstantin Boudnik 2011-11-16, 02:06
+
Doug Cutting 2011-11-16, 17:15
+
Konstantin Boudnik 2011-11-16, 17:24
+
Scott Carey 2011-11-16, 18:15
Copy link to this message
-
Re: [DISCUSS] Apache Hadoop 1.0?
On 11/16/2011 10:15 AM, Scott Carey wrote:
> IMO what is important from the development and maintenance perspective is
> the _meaning_ of the
> major.minor.patch numbers as described in my previous message.
>
> If a minor version number bump means that it is a superset of the previous
> release and is backwards compatible, then that requirement on its own
> answers whether 0.22 can become 1.1, or if it must be a 2.0 release.
>
> Whether hadoop starts using a new meaning for major.minor.patch is what is
> of interest to me; starting at 1.x.y or 20.x.y or 999.x.y is marketing.

Scott, this is a great point.  Thanks for making it.

> The version number is completely meaningless on its own, pure marketing.
> However, if the numbers gain meaning through a clear definition of what
> the major.minor.patch numbers signify, then there is meaning and structure
> going forward.
> The current state of affairs seems to be:
> major:  always 0
> minor:  potentially big changes; almost always breaks wire compatibility;
> occasionally breaks API backwards compatibility
> minor:  typically bug fixes only; 'bug fix' not well defined; almost never
> breaks API or wire compatibility

Long ago I proposed such rules for Hadoop releases at:

http://wiki.apache.org/hadoop/Roadmap

These state that pre-1.0 releases behave roughly as above.

> I think the community can decide two things independently:
>
> - Should 0.20.20x be renamed 1.0.y ?  (perhaps not, perhaps 0.23 should be
> 1.0 and the others left alone).
> - Should hadoop adopt a new clear definition of major.minor.patch number
> significance?

Would you care to call a vote on one or both of these?

> example proposal:
> * major version number increment: signifies breaks in API backwards
> compatibility and/or major architecture overhauls.
> * minor version number increment: signifies possible API changes, but
> maintains API backwards compatibility.  Wire compatibility may break (see
> release notes).  Included functionality is a superset of previous minor
> release.
> * patch version number increment: signifies a release where all
> improvements are fully backwards compatible with the previous patch
> version, including wire format.

This is also similar to what the Roadmap wiki page indicates for
post-1.0 releases.

Renaming things after the fact to try to make them consistent when the
prior rules weren't consistently followed is not easy.  Instead we might
better focus on rules that we intend to obey for releases going forward
and then obey them.

> Whatever the meaning of the numbers turns out to be will dictate whether
> releases after a 1.0.x need to be 2.0.x or can be 1.1.x

Good point.  The most accurate approach would probably be to call each
existing branch a distinct major release.  Dropping the leading zero
would reduce confusion and avoid marketing but would still combine
0.20.x and 0.20.20x which perhaps ought to be considered separate major
releases.  For me this is however a reasonable tradeoff since we're
better off focusing on improving things in the future than arguing about
marketing and how to hide our past versioning mistakes.

Doug
+
Matt Foley 2011-11-16, 21:11
+
Owen OMalley 2011-11-16, 21:37
+
Joe Stein 2011-11-16, 21:53
+
Roman Shaposhnik 2011-11-16, 23:05
+
Andrew Purtell 2011-11-16, 23:40
+
Arun C Murthy 2011-11-17, 00:03
+
Eric Yang 2011-11-17, 00:05
+
Konstantin Boudnik 2011-11-17, 05:54
+
Arun C Murthy 2011-11-16, 22:43
+
Doug Cutting 2011-11-16, 23:02
+
Arun C Murthy 2011-11-16, 23:05
+
Arun C Murthy 2011-11-16, 23:13
+
sanjay Radia 2011-11-17, 01:11
+
Nathan Roberts 2011-11-16, 23:51
+
Doug Cutting 2011-11-17, 00:13
+
Scott Carey 2011-11-17, 01:37
+
Scott Carey 2011-11-17, 02:06
+
Steve Loughran 2011-11-17, 10:45
+
Roman Shaposhnik 2011-11-17, 16:33
+
Arun C Murthy 2011-11-17, 19:09
+
Roman Shaposhnik 2011-11-17, 19:31
+
Steve Loughran 2011-11-21, 11:17
+
Andrew Purtell 2011-11-17, 21:07
+
Mahadev Konar 2011-11-17, 21:12
+
Andrew Purtell 2011-11-17, 21:28
+
Alejandro Abdelnur 2011-11-17, 19:17