Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(dev/release#17) Extension UI - Show developmental icon for alpha/beta-stage extensions #20302

Merged
merged 3 commits into from
May 17, 2021

Conversation

totten
Copy link
Member

@totten totten commented May 14, 2021

Overview

Each version of an extensions is published with two fields, <version> (e.g. 1.1) and <develStage> (e.g. alpha).
Confusingly, the two fields sometimes convey redundant information - but not always. A few cases:

  • (A) Sometimes a <version> as 1.0-alpha1, 1.2.beta2, or 2.3dev. This would make sense if the
    developer does formal tagging/releasing for developmental versions. (In this case, you don't really need the
    icon - because the version-number tells you.)

  • (B) Other times, you might have a <version> which simply says 1.0 or 2.0 -- and then supplemental
    information where the <develStage> says alpha or beta. This could make sense if the developmental
    version is being continuously updated without formal tags/releases.

  • (C) Under dev/release#17, we have another case -- where the core-extensions have version#s which match the
    core version# (because they are released together), but the devel-stage of the extension is only
    alpha/beta (because the extension is still evolving/optional/not-fully-supported).

Before

The "Development Stage" is not specifically indicated. This is OK for (A) but not (B) or (C).

Screen Shot 2021-05-13 at 11 12 53 PM

After

There's an icon in the table to signal the development stage. So the stage is indicated in all cases (A,B,C).

Screen Shot 2021-05-13 at 11 11 59 PM

To see that this code is unused, simply grep the entire source-tree for `upgradable`
and `upgradeVersion`. There is nothing that would plausible set these fields.

I think this is left-over from an older UX. When there's an upgrade available in this UX, it shows
an alert box under the "Description".
…a-stage extensions

Extensions are published with two fields, `<version>` (e.g.  `1.1`) and `<develStage>` (e.g.  `alpha`).
Confusingly, the two fields sometimes convey redundant information - but not always. A few cases:

* For example, sometimes a `<version>` as `1.0-alpha1`, `1.2.beta2`, or `2.3dev`. This would make sense if the
developer does formal tagging/releasing for developmental versions. (In this case, you don't really need the
icon - because the version-number tells you.)

* Other times, you might have a `<version>` which simply says `1.0` or `2.0` -- and then supplemental
information where the `<develStage>` says `alpha` or `beta`.  This could make sense if the developmental
version is being continuously updated without formal tags/releases.

* Under dev/release#17, we have another case -- where the core-extensions have version#s which match the
core version# (because they are released together), but the devel-stage of the extension is only
alpha/beta (because the extension is still evolving/optional/not-fully-supported).

Before: The "Development Stage" is entirely obscure.

After: There's an icon in the table to signal the development stage.
@civibot
Copy link

civibot bot commented May 14, 2021

(Standard links)

@colemanw
Copy link
Member

This looks fine. I made a couple tweaks to the markup and css, and avoided going down the rabbit-hole of further improvements to that ancient extension management screen. I think there was some effort being made to rewrite that screen completely, which would be wonderful.

@eileenmcnaughton eileenmcnaughton merged commit 4422e67 into civicrm:master May 17, 2021
@totten totten deleted the master-extver-ui branch May 17, 2021 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants