opened
witchang
username_0
we use https://github.com/greenplum-db/gpdb/tree/6.3.0 to build greenplum ,but start greenplum,it display "master Greenplum Version: 'PostgreSQL 9.4.24 (Greenplum Database 6.0.0-beta.1 build dev) on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit compiled on Jan 27 2020 00:05:58'   "
why the version is beta??
greenplum  6.3.0 version is beta
issue
created
danielgustafsson
username_1
The build is picking up the version in `configure.in` which needs to be adjusted during packaging. There is no automatic way to do this at the moment however.
comment
created
kmacoskey
username_2
I think it's necessary to expand on this a bit more before the next option. The version of Greenplum Database (the tag) is not impacted by only the source code in this repository. Because the Greenplum Database version is the same as the "Pivotal Greenplum" version (Pivotal Greenplum is a suite of many products, both OSS and not), the version chosen is based on many other processes and product releases. While it hasn't yet occured, the time will come for branches like 5X_STABLE where the same commit can have multiple tags because something other than the source code here necessitates a new release. That alone could conflict with the idea of making a new commit when there is a new release among other problems.

4. We separate the Greenplum Database version from the "Pivotal Greenplum" version
   - Business goals can be separated from source code processes, which makes option (3) more possible
   - Could be confusing for enterprise users to suddenly version what looks like the same product into two different versioned products
   - We can't make this a reality by making code changes - It requires business changes
comment
created
asimrp
username_3
Thank you for the elaborate description @username_2, the problem is clear in my head now.  I'm wondering how option 2 - modify source code to remove the need to create commits - would look like.  Would the version string be maintained outside of source repository?
comment
created
danielgustafsson
username_1
Well, the project has no business goals per se, but given that the project originated within Pivotal and Pivotal employs the vast majority of people working it, the business goals of Pivotal shines through and has in this case dictated process. So this is a change of process, with which the business goals of Pivotal (and everyone else) can remain and probably even simplified as there is no need to synchronize.
comment
created
witchang
username_0
so，in production，which branch we can use，6X_stable，or 6.3.0tag，just manual modify configure.in or orther way


发自我的iPhone

------------------ Original ------------------
comment
created
danielgustafsson
username_1
For production I recommend using the minor-rev release tag, in this case the 6.3.0 tag.
comment
created
witchang
username_0
we have modify the file "configure.in"
old content is : AC_INIT([Greenplum Database], [6.0.0-beta.1], [support@greenplum.org]);
new content is :AC_INIT([Greenplum Database], [6.3.0], [support@greenplum.org]);
but nothing changed
comment
created
danielgustafsson
username_1
Did you "make distclean" before rebuilding?  What does ./getversion in the root
of the source tree give?
comment
created
witchang
username_0
we run "make distclean",but found error as below:
You need to run the 'configure' program first. See the file
'INSTALL' for installation instructions.
make: *** [distclean] 错误 1
comment
created
kmacoskey
username_2
@username_3 

> On Mon, Jan 27, 2020 at 9:49 PM Asim R P <notifications@github.com> wrote:
> Thank you for the elaborate description @username_2, the problem is clear in my head now. I'm wondering how option 2 - modify source code to remove the need to create commits - would look like. Would the version string be maintained outside of source repository?

Yes, this would essentially be the end result. We already somewhat do this in existing processes. However where it breaks down is the conflation of multiple versions. If we use the same version for both the "Server" ("Greenplum Database") and "Pivotal Greenplum" then even if we store one version in a private location and the other in the OSS repository, we will still have process conflicts.

@username_1 

> On Tue, Jan 28, 2020 at 4:15 AM Daniel Gustafsson <notifications@github.com> wrote:
> I will object strongly to tagging a new release to satisfy the needs of a distribution.

As will I, doing this is a symptom of a misaligned process. We thankfully haven't reached this day yet, but unless we change something it's going to inevitably become a topic of issue. I'd much rather fix the problem when it's not actively happening.

> On Tue, Jan 28, 2020 at 4:15 AM Daniel Gustafsson <notifications@github.com> wrote:
> This is what I think must happen.
> Pivotal Greenplum should be a distribution consuming Greenplum Database, just like any other Greenplum derivative. Greenplum Database ships the branch based on HEAD, and distributions are then free to pick any other point in history and/or add additional code and value-adds before wrapping their releases.

I'm very much an advocate for Option 4. Pivotal Greenplum is downstream from Greenplum Database and should be treated as such as it relates to versioning and processes. While it makes me slightly biased, Option 4 can significantly reduce the complexity in the current release process.


When I stated the Option 4 requires business changes, this is mostly what I was thinking. I have found surprisingly few internal R&D stakeholders, other internal stakeholders, or end users that have a clear understanding about what the difference is between "Pivotal Greenplum", "Greenplum Database", and the "Server". I think it will be non-trivial to get everyone aligned on this same topic, with the opposition being that we should solve this with technical solutions and not try to change product taxonomy for a problem that not everyone will agree is actually a problem.

---

The release engineering team is committed to supporting Option 2, 3, and 4. Option 1, while an option, will likely create a lot of work for us specifically (among others) and it only adds even more complexity. The remaining options can significantly reduce the complexity and conflicting processes. Other options are of course welcome and needed.

RelEng can advocate and discuss this topic but we have thus far made little impact in something actually changing. We are downstream of the Server and in no way should make the final decision. I believe change will require support from all of users that share code ownership in this repository and greater visibility of this topic to all of the related stakeholders (internal and external).
comment
closed
lij55
username_4
issue