Finding the latest LTS version of XWiki programmatically

Development
#1

Hi devs,

I’ve heard someone doing the following to find the latest LTS version of XWiki:

curl -s http://www.xwiki.org/xwiki/bin/view/Download/| grep 'Long Term Support' | grep -Po '(?\<=\<span class="download-version fill-LTS">)(\\d+.)+\\d+(?=)'

That seems convoluted and not stable, so I thought about starting this brainstorming to add a FAQ entry on xwiki.org on how to achieve this task properly.

Some ideas:

WDYT?

Thanks

1 Like
#2

Do you have a single source of truth for the XWiki version? E.g. does your build or publish process tag a Git commit, deploy artifacts somewhere, etc.? Or are all the sites mentioned updated by a human?

#3

Reading https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices#HReleaseCyclesandReleaseStrategy I see you do not have lts tags in Git - which could be ok, it is considered bad practice to “move” tags (although I’m personally evaluating that for some personal projects, to tag the last succesfully deployed commit).

#4

Hello,

Excellent ideas, really having a dedicated FAQ entry will be helpful.

Why not bind it into the What’s New page in the XWiki instance instead of creating a new separate page?

#5

The places where we link the concept of “LTS” to a version are the one I listed above, namely:

Our release process updates all these places. See https://dev.xwiki.org/xwiki/bin/view/ReleasePlans/

Indeed we don’t do this but mostly because we’ve never needed it.

The What’s New app is about various news about XWiki, not just about releases (and there’s no concept of LTS in it). It also doesn’t offer a programmatic way to query it ATM.

Thanks

#6

Yes, the versions can only be found in https://maven.xwiki.org/lts/Packages (and its compressed version).

Maybe you mean https://newreleases.io/ (I’m using it to get notifications about new versions of various stuff, including XWiki dependencies, even if that usage is fading away in favor of Renovate these days on my side) ?

Maven Central

We could use Maven central API to get the latest version of xwiki-commons for example. https://search.maven.org/solrsearch/select?q=g:org.xwiki.commons%20AND%20a:xwiki-commons&rows=20&wt=json seems to be doing the job.

GitHub:

Some softwares I’m following are using the concept of “pre-release” that you can set in a GitHub releases to mark the difference between releases for the LTS branch and release for the current dev branch. And then they can use the github API to find and download the latest version, depending on the configured channel.
Now I don’t think we really need that level of complexity, it would IMO be good enough to just:

  • use the github API (on xwiki-platform repository, for example) to get the latest version (X.Y.Z)
  • and consider
    • X.Y. as the current stable version
    • X-1. as the current LTS version

In both of those cases, it would mean for us to start creating actual GitHub releases (we just have the tags currently), but it’s probably a good thing anyway. It should be easy to automate this in the release script (for the content of that release note, just putting a link to the XWiki release note is good enough IMO).

#7

ok, I guess you’d need to read up to the bottom of the text to find out, which is cumbersome and slower than it could be.

I was thinking about another one that had the concept of LTS and that didn’t need an account to view stuff.

There’s no concept of LTS in Maven.

That still sounds complex vs being able to ask for what is the last LTS. Isn’t it possible to tag a release as LTS in GitHub and then ask for the latest one tagged with LTS using the API?

Proposal

ATM, it feels like the best source of truth for the LTS should be in our code or infra somewhere.

What about simply adding a boolean xproperty to indicate a LTS release in ReleaseNotes.Code.ReleaseNoteClass? Then we should be able to write a URL to query it and return the last one. And we could also show the LTS status in the LT at ReleaseNotes.Code.ReleaseNoteClass.

#8

The reason I say that is because relying on some external tool is dangerous as we risk loosing the history info if we change tools in the future.

#9

Does not ring a bell, sorry.

You don’t need an account to view stuff, the point of the account is to receive notifications.

As I indicated, you have the concept of “pre-release” in GitHub and in such a case you would set as “pre-release” everything which is not LTS.

Yes, IMO the best source of information is where the reference source is located, so GitHub.