hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lei Chang <lei_ch...@apache.org>
Subject Re: Confusion around HAWQ versions in JIRA
Date Thu, 07 Jul 2016 00:42:52 GMT
I remember the discussion happened in pivotal internally long long time
ago, cannot remember it is before or after oss.

I think I can summarize the pros and cons from all the discussions:

1. current hawq 4-digit versioning

Make upgrade process quite clear and keep all the compatibility for
packages, libraries and external tools. Did not see issues from past
experience.

2. 3-digit semantic versioning

Show API changes from the number, this is good. But the APIs of a database
is quite complex, including SQL, udfs, jdbc, odbc, data formats, catalog,
tools.... It will make number changes somewhat unclear and very frequent.
And it is quite difficult to trace upgrade efforts. And it also has
compatibility issues.

And from discussion from this thread, looks most guys like option 1.

Cheers
Lei


On Thu, Jul 7, 2016 at 4:48 AM, Ting(Goden) Yao <tyao@pivotal.io> wrote:

> I still remember we had a huge discussion last year right after open
> sourcing HAWQ and decided to switch from 4 digits to 3 digits semantic
> versioning.
> I can dig into email box to pull out the details. Can we check if all the
> points from then are still valid or not?
>
>
> On Wed, Jul 6, 2016 at 1:46 AM Xiang Sheng <xsheng@pivotal.io> wrote:
>
> > It is indeed better to keep the output of SQL 'select version();' with
> the
> > hawq version.
> >
> > Since the suffix '-incubating' indicates the project property, we should
> > keep it before the project promoted to apache standard.
> > So I think the output of the 'select version();' should add the suffix.
> And
> > obviously 4 digit number with suffix '-incubating' is more reasonable.
> >
> > On Wed, Jul 6, 2016 at 4:27 PM, Ming Li <mli@pivotal.io> wrote:
> >
> > > As for the version with postfix '-incubating', if after our project be
> > > promoted to apache standard project, the version number still grows, so
> > > from the perspective of service, it seems the postfix is useless.
> > >
> > > On the other hand, the output of SQL 'SELECT version();' doesn't
> include
> > > any
> > >  '-incubating',  it is better to keep it same with the hawq version.
> > >
> > > So I prefer to use just 4 digit number without any postfix
> '-incubating'.
> > >
> > >
> > > On Wed, Jul 6, 2016 at 4:09 PM, Hong Wu <xunzhangthu@gmail.com> wrote:
> > >
> > > > For simplify, I prefer using the 4-digit mode.
> > > >
> > > > Best
> > > > xunzhang
> > > >
> > > > 2016-07-06 16:07 GMT+08:00 Jiali Yao <jyao@pivotal.io>:
> > > >
> > > > > +1 for consolidating  the version.
> > > > >
> > > > > For 4-digit number, from the concept described above, I think 4
> digit
> > > > make
> > > > > more sense. And from it, user can easily know whether specific
> > upgrade
> > > > > process needed or just binary switch if fine.
> > > > > Based on that, for the "2.0.0", "2.0.0-incubating" or
> > > > "2.0.0.0-incubating".
> > > > > I prefer to 2.0.0.0-incubating since it would be consistent in JIRA
> > and
> > > > > code.
> > > > >
> > > > > Thanks
> > > > > Jiali
> > > > >
> > > > >
> > > > > On Wed, Jul 6, 2016 at 3:56 PM, Lei Chang <lei_chang@apache.org>
> > > wrote:
> > > > >
> > > > > > On Wed, Jul 6, 2016 at 3:17 PM, Vineet Goel <vvineet@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > Apologies for any confusion. Let me expand further:
> > > > > > >
> > > > > > > 1) My proposal was to update the JIRA versions. I didn't
think
> > > > > > > 2.0.0-incubating and 2.0.0 are the same, we should either
> > > consolidate
> > > > > > them
> > > > > > > as one, or change the JIRA version numbers to be numerically
> > > > different.
> > > > > > > Version 2.0.0 shows 5 open JIRAs that may or may not belong
to
> > > > > > > "2.0.0-incubating" release. See link:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/HAWQ/fixforversion/12334195/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
> > > > > > > vs
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/HAWQ/fixforversion/12334000/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
> > > > > > >
> > > > > > > We should update the 5 JIRAs listed in 2.0.0 with the correct
> > > status
> > > > > and
> > > > > > > fix versions. This will make it easy to track the upcoming
> > release.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > Agree. What I meant is also to consolidate the two into
> > > > > "2.0.0-incubating"
> > > > > > or "2.0.0.0-incubating" depending on which version schema we
will
> > > > choose.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > 2) Regarding the 4-digit versioning in the code, that's
a good
> > > > > discussion
> > > > > > > to have.
> > > > > > > What is the proposed convention for managing the 4 digits
and
> > what
> > > > sort
> > > > > > of
> > > > > > > code/API changes trigger a change in specific digits ?
It would
> > be
> > > > good
> > > > > > to
> > > > > > > discuss the details.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > The 4-digit x.y.z.w versioning is:
> > > > > >
> > > > > > x: means major release
> > > > > > y. means minor release
> > > > > > z. means bug fix release
> > > > > > w. used for hot fix release
> > > > > >
> > > > > > Catalog and data format changes need x or y change. From the
> number
> > > > > > changes, end users know whether it needs a hawq upgrade. for
this
> > > > scheme,
> > > > > > API changes are not reflected in the number. For 3-digit semantic
> > > > > > versioning, the rules to increase the number is quite different,
> > the
> > > > > number
> > > > > > change does not reflect catalog changes or data format changes
> but
> > it
> > > > > > reflects API changes.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > > -Vineet
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jul 5, 2016 at 11:35 PM, Ruilong Huo <rhuo@pivotal.io>
> > > > wrote:
> > > > > > >
> > > > > > > > I would prefer the option 1 to keep the 4-digit versions.
> This
> > > > > > mechanism
> > > > > > > > address the compatible issues of library in a more
proper
> > manner.
> > > > > > > >
> > > > > > > > PS, here are some background of the hawq versioning
policy
> > which
> > > > > might
> > > > > > > > help:
> > > > > > > > Postgres based systems, including GPDB and HAWQ, have
> > > > > > > > the notion of "MODULE_MAGIC" which is intended for
the
> > > > > > > > purpose of guaranteeing version compatibility.  In
addition
> > > > > > > > to the "MAGIC NUMBER", defined as the Major.Minor
version
> > > > > > > > , GPDB and HAWQ also have the notion of a "MAGIC
> > > > > > > > PRODUCT" which GPDB uses to differentiate itself from
> > > > > > > > Postgres and provide clear messages regarding "this
> > > > > > > > library was built against Postgres" this mechanism
> > > > > > > > could be easily employed to differentiate HAWQ and
GPDB
> > > > > > > > and allow basing the "MAGIC NUMBER" off of the HAWQ
version
> > > > > > > >  instead of the GPDB version as it does today.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Ruilong Huo
> > > > > > > >
> > > > > > > > On Wed, Jul 6, 2016 at 2:26 PM, Radar Da lei <
> rlei@pivotal.io>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > For Lei's proposal, I would prefer option 1 for
below
> > reasons:
> > > > > > > > >
> > > > > > > > > 1. Save time we may spend to solve incompatible
issues.
> > > > > > > > > 2. It will be hard to maintain semantic version
if we
> > increase
> > > > > major
> > > > > > > > > version every time when we are changing catalog
and
> > interface.
> > > If
> > > > > so,
> > > > > > > > HAWQ
> > > > > > > > > version will reach 10.0.0 very soon.
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Radar
> > > > > > > > >
> > > > > > > > > On Wed, Jul 6, 2016 at 1:58 PM, Lei Chang <
> > > lei_chang@apache.org>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > This is indeed a confusing issue. I am even
confused by
> > what
> > > > > Vineet
> > > > > > > > > > proposed.
> > > > > > > > > >
> > > > > > > > > > There are several versions currently used
across the
> > systems:
> > > > > > > > > >
> > > > > > > > > > 1) the 3-digit JIRA versions: currently
it has
> > > 2.0.0-incubating
> > > > > and
> > > > > > > > > 2.0.0.
> > > > > > > > > > and i think they are the same, "2.0.0-incubating"
is more
> > > > formal
> > > > > > for
> > > > > > > > > > incubating project.
> > > > > > > > > >
> > > > > > > > > > 2) the 4-digit versions in the code which
is inherited
> from
> > > > > > postgres
> > > > > > > > and
> > > > > > > > > > will be shown in "select version()" command;
 it is
> > somewhat
> > > > > > related
> > > > > > > to
> > > > > > > > > > library compatibility and it is also related
to third
> party
> > > > > tools.
> > > > > > > Some
> > > > > > > > > > tools may read and parse versions, and changing
from 4
> > digit
> > > > to 3
> > > > > > > digit
> > > > > > > > > > might introduce some unknown incompatibility
issues.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > So currently there are 2 options:
> > > > > > > > > >
> > > > > > > > > > 1. Keep 4-digit version scheme, changing
everything to 4
> > > digit
> > > > > > > > versions,
> > > > > > > > > > and release it.
> > > > > > > > > >
> > > > > > > > > > 2. Change everything to 3 digits and this
might introduce
> > > some
> > > > > > > unknown
> > > > > > > > > > incompatibility issues.
> > > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > > >
> > > > > > > > > > Cheers
> > > > > > > > > > Lei
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Jul 6, 2016 at 1:21 PM, Vineet Goel
<
> > > > vvineet@apache.org>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 1) Proposal - we can rename the 2.0.0
version to
> > > > > 2.0.1-incubating
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > next planned maintenance release (for
now). All JIRAs
> > > > targeted
> > > > > > for
> > > > > > > > > 2.0.0
> > > > > > > > > > > should be evaluated to see if any belong
to the scope
> for
> > > the
> > > > > > > > upcoming
> > > > > > > > > > > 2.0.0-incubating
> > > > > > > > > > > release or not.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > 2) Regarding comments on JIRA-875,
I have created a new
> > > JIRA
> > > > > > > > (HAWQ-895)
> > > > > > > > > > for
> > > > > > > > > > > the investigation on migrating to semantic
versioning.
> > That
> > > > > > raises
> > > > > > > > the
> > > > > > > > > > > question, should version 2.0.0-incubating
really be
> > > > > > > > 2.0.0.0-incubating
> > > > > > > > > ?
> > > > > > > > > > > https://issues.apache.org/jira/browse/HAWQ-895
> > > > > > > > > > >
> > > > > > > > > > > Thanks
> > > > > > > > > > > -Vineet
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 5, 2016 at 5:09 PM, Goden
Yao <
> > > > godenyao@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > >
> > > > > > > > > > > > I want to raise some concerns
around HAWQ versions we
> > > used
> > > > in
> > > > > > > > Apache
> > > > > > > > > > > JIRA.
> > > > > > > > > > > > We right now have:
> > > > > > > > > > > >
> > > > > > > > > > > >    - 2.0.0-incubating (this is
the upcoming release
> > we're
> > > > > > working
> > > > > > > > on)
> > > > > > > > > > > >    - 2.0.0 (this was used for
JIRAs after originally
> > > > planned
> > > > > > > > > > > >    2.0.0-incubating) , now I see
a little bit issue
> if
> > we
> > > > > > releae
> > > > > > > > > > > >    2.0.0-incubating , what leaves
with items
> associated
> > > > with
> > > > > > this
> > > > > > > > > > > version?
> > > > > > > > > > > >    - 2.1.0 - supposedly , this
is the next minor
> > release
> > > > > > > > > > > >    - 3.0.0 - supposedly, this
is the next major
> release
> > > > > > > > > > > >    - Backlog
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Then I see this JIRA:
> > > > > > > > https://issues.apache.org/jira/browse/HAWQ-875
> > > > > > > > > > > > (*Upgrade
> > > > > > > > > > > > HAWQ version to 2.0.1.0*), which
is not a version
> > listed
> > > on
> > > > > the
> > > > > > > > > release
> > > > > > > > > > > > page.
> > > > > > > > > > > > Can we:
> > > > > > > > > > > >
> > > > > > > > > > > >    - Clarify which version is
for which release
> (goals,
> > > > > > purpose,
> > > > > > > > > etc.)
> > > > > > > > > > > see
> > > > > > > > > > > >    example I did for 2.0.0-incubating:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/HAWQ/HAWQ+Release+2.0.0-incubating
> > > > > > > > > > > >
> > > > > > > > > > > >    - When you file JIRA, make
sure you have a
> targeted
> > > > > version
> > > > > > > for
> > > > > > > > it
> > > > > > > > > > so
> > > > > > > > > > > >    it's easy to track from release
perspective.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks
> > > > > > > > > > > > -Goden
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Xiang Sheng
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message