IMO 1.0 for a product typically promises :
1) Reasonable stability of interfaces.
Typically only major version changes break interface compatibility.
While we are at 0.x, it seems to be considered 'okish' to violate this :
but once you are at 1.0 and higher, breaking interface contracts will
not be desired behavior.
We should be reasonably confident about the interfaces we expose to
users : this includes the shell, exec envs, properties, api and spi's.
(This also depends on hadoop btw).
2) Reasonable stability and code quality.
Typically a major release promises reasonable rigor in terms of code
quality, stability and functionality.
As mentioned, it is easier to get amazon, etc to move to pig 1.0, but
probably not so for 0.7 or 1.0.1 or 1.1, etc. Declaring something as 1.0
typically has this expectation.
Considering the pretty invasive changes which has happened off late,
maybe we do need to have a cool off period for the code to settle and
focus on the bugs instead of features if we need a 1.0 release ?
Though as a developer, we always want to work on new & exciting things,
we should balance it against user expectations for a stable product.
3) reasonable 'polish' in the product.
In general, it is not very easy to use pig - and it keeps violating
principle of least surprise even after having used it for 3+ years now.
Typically related to schema, parsing, changing udf contracts, property
interactions, multi-query optimization effects, null
handling/interactions and the like.
A lot of it is probably just due to idioms and expectations which are
not well known, bugs which should be filed, problems of trying to debug
in a distributed cluster, constructs which are not
adequately/well-defined, and lot due to mismatch between a novice user
and pig-dev expectations.
We tend to work around/avoid a lot of these issues without a second
thought, but exposing to someone new does bring out the confusion.
Considering the scope of pig, probably this is a pie in the sky goal -
but it definitely would be good if pig "felt" stable and usable without
need for too many caveats/gotchas.
Until these are "reasonably" well tackled, imo, it is not a good idea to
go 1.0.
Regards,
Mridul
On Thursday 03 March 2011 06:22 AM, Olga Natkovich wrote:
Pig Users and Developers,
We are starting to plan the work after Pig 0.9. One thing we need to decide is
what name/number to give to the next release: Pig 0.10 or Pig 1.0.
I believe that we are ready to declare 1.0. Here are my reasons:
(1) We are mature enough and produce good quality releases
(2) Our interface no longer change in major ways
(3) We have a growing user community and we want the newcomers to know that
our releases are stable
(4) If the next release is 0.10 and we decide that we should switch on the
following release going from 0.10 to 1.0 will generate a lot of confusion.
I wanted to start this conversation and see what others think before deciding
if it is worth while to call a vote.
Olga
