[jbosstools-issues] [JBoss JIRA] (JBIDE-22355) Build qualifier still say Alpha2

[Nick Boldt (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238834#comment-13238834 ] 

Nick Boldt commented on JBIDE-22355:
------------------------------------

TL;DR: 

Let's stop using BUILD_ALIAS entirely for component jobs, and use BUILD_ALIAS as a suffix qualifier for JBT/DS deliverables only.

Discussion:

+1 for the idea of all local builds having a BUILD_ALIAS = SNAPSHOT, and for Jenkins-based builds, we set BUILD_ALIAS={the actual quality we think we're doing*}

where * = Alpha1, Beta1, CR1, Final/GA

Since the quality is entirely arbitrary based on our own "feelings" of how well we're doing (much like Early Access vs. Supported), we can change the BUILD_ALIAS across all components as we move from Alpha to Beta to CR to Final phases of development. These phases could be hardcoded dates (like we did for JBDS 9 and 9.1) or they could be on-the-fly declarations a few days before the Thursday night build.

But then again, if we're TRULY being agile, we're ALWAYS Final, because each sprint releases something that's stable enough to not break previous. We're always incrementally improving, but never by releasing something that's broken/unsupported. If it's unsupported, it's unreleased (and perhaps in a topic branch until it's ready to merge to master). 

Thus... if quality statement is moot because We're Agile now, we could eliminate the BUILD_ALIAS entirely, and just move to using timestamps, as we used to Back In The Day and how I used to build all the Modeling projects at Eclipse.

{quote}not sure how we then actually keep track of when something is Final vs just intermediate builds.{quote}
We will have a buildinfo.json for the build we declare is 10.0.0.GA or 4.4.0.Final. That will be the Final one; everything else is just an intermediate toward that release.

Similarly, if we decide the build to be released publicly in June is to be called Alpha3, then that Alpha3 build will contain a buildinfo.json file, which can be used to create all the Alpha3 tags.

---

To address the issue of "building locally against the latest local/remote content"... whether we use a BUILD_ALIAS or not, here's the workflow:

a) build Openshift locally using `mvn verify`. maven fetches latest Base and Server from remote, caches them in ~/.m2
b) fix a bug in Openshift & rebuild locally using `mvn verify`. If using `-o`, use only offline stuff. If using `-U`, fetch from remote again looking for updated snapshots. If using `-Dtycho.localArtifacts=ignore` ignore ANY local artifacts in your ~/.m2 in favour of re-fetching stuff from remote. (Ref: https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/build_from_commandline.adoc )
c) realize there's a bug in Server! So, rebuild Server locally using `mvn *install*` instead of `mvn verify` to publish those bits into your local ~/.m2
d) rebuild Openshift locally. This time, your locally installed Server bits will WIN against anything remote. Hooray! You fixed the bug and verified your fix locally.
e) submit PR against Server. Wait for review.
f) PR is pushed; Server is rebuilt in Jenkins
g) rebuild Openshift locally. This time, your locally installed Server bits will LOSE against the new remote bits, because the timestamp is newer on remote than in your local repo. No ~/.m2 cache cleanup needed.

If you have locally built bits with BUILD_ALIAS =  Alpha1 in them and there's remote BUILD_ALIAS = Alpha2 bits, those remote bits will ALWAYS win because of OSGi qualifier rules. So to create local bits that win against the remote stuff, you need a newer BUILD_ALIAS = Alpha2. For JBDS 9.x, this was achieved by setting your root pom to use the latest Alpha2 parent pom, and the parent pom would hardcode the BUILD_ALIAS = Alpha2. But if we eliminate BUILD_ALIAS entirely, timestamp-based sequencing will still work - that's just how OSGi works. 

And if we want to continue to use BUILD_ALIAS for the things we actually release (aggregate update sites/zips, standalone browsersim, source zips, installers, etc.), we can totally still do that either in Jenkins or as part of the staging/release process. 

So when QE and Dev are working together, they would be referencing specific builds (eg., rather than "the B123 Alpha1 CI build of Server", it would just be "the B123 CI build of Server").
When QE and releng are working together, they would be referencing specific builds (eg., "the B234 Alpha1 JBT/devstudio staging builds" or the "Alpha1 JBT/devstudio released builds").
When releng and PgM are working together, they would be referencing specific builds (eg., "the B234 Alpha1 devstudio staging build" or the "Alpha1 devstudio released build").

Since BUILD_ALIAS is now only a cosmetic / productization label, I would suggest if we intend to keep using it for aggregates and products, we use it as a qualifier *SUFFIX* instead of a *PREFIX* so people get used to timestamps as the OSGi sequencer, NOT the BUILD_ALIAS label. And of course once something goes to CSP, we would continue to use ONLY the BUILD_ALIAS, hiding the internal detail of timestamp.

> Build qualifier still say Alpha2
> --------------------------------
>
>                 Key: JBIDE-22355
>                 URL: https://issues.jboss.org/browse/JBIDE-22355
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build
>            Reporter: Mickael Istria
>            Assignee: Nick Boldt
>            Priority: Critical
>             Fix For: 4.4.0.Alpha2
>
>
> Build qualifiers, parent pom version, and version of parent pom referenced by components are still Alpha1.
> All those should be moved to Alpha2 (they should be moved just when branching/releasing actually)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)