Poll/Discussion: frequency of uPortal releases

[Benito Gonzalez]

Hi folks,

I haven't been satisfied with the inconsistent timing of uPortal releases. I expect many of you share this feeling. What to do?

My suggestion is we plan regular releases. How often and at what level?

Considerations

- How often is too often for most institutions?

- What bandwidth do developers have to cut the releases?

- Should effort go into the latest release or do we want to make it easier for implementers to stick to a particular feature release and only pick up patches?

- Does Semantic Versioning still work?

- Should we change our major number (e.g. 5) to the current year?

My suggestions: 

1. One major release each year, with quarterly feature releases between; patch releases as needed.

1. One major release semi-annually, with biannual feature releases between; patch releases as needed.

My Take

- How often is too often for most institutions?

As someone that managed a uPortal service at a university, upgrading more than once a year was a challenge. Skipping a year or two was expected. Now, security patches are deployed but feature releases are not critical. 

- What bandwidth do developers have to cut the releases?

We have been slow to cut releases. We can improve this by teaching other committers how to cut a release. This should not be a challenge, especially if there is an established schedule.

- Should effort go into the latest release or do we want to make it easier for implementers to stick to a particular feature release and only pick up patches?

Again, as a previous manager, we were on an older release. It was a major investment of time and resources to upgrade. I would have loved patch releases for the feature release I was on. That said, supporting patch releases for several feature releases is not practical. The reality is we should facilitate implementers on older releases to easily pick up patches, but not offer patch releases for older versions.

- Does Semantic Versioning still work?

Mostly, yes. We have had some feature releases where configuration required changes. If we had regular releases, some of these could have been postponed to the next major release.

- Should we change our major number (e.g. 5) to current year?

I really like this! Those outside our community have heard about uPortal but have no clue if it's active. uPortal 5 indicates little. And if the person thinking about uPortal knows uPortal 4 as released in 2010ish, then they would likely assume uPortal is out of date. Release of uPortal 2021 vs. uPortal 2022 strongly implies we are current.

By committing to something like this, we will have a framework to talk about when something will be released and what changes go in which builds. This is great for our roadmap!

If you read this far, I thank you. Hopefully, I can cajole you into replying, even if it's a simple "sounds good" or "not important to us; do what you need". Even better, raise some considerations I overlooked or add your take on this topic.

Have a great weekend!

-bjagg

--

Benito J. Gonzalez

Software Architect

Unicon, Inc.

Voice:  209.777.2754

 Text:  209.777.2754

Email:  bgon...@unicon.net

GitHub:  bjagg

GitLab:  bjagg

BitBucket:  bjagg

[Jim Helwig]

Thanks for sharing these thoughts, Benito.

 

I have become a believer in semantic versioning. I think it helps implementers understand the level of effort needed to upgrade or apply a patch.

 

I agree that naming releases with the year and then making sure we actually released each year would give a signal that the project is alive, I think that is only for someone giving it a superficial glance. But it only takes a quick glance at the releases page to see what the dates are. I don’t think we would gain any more adopters simply by changing how we name releases. I don’t think that strategy is widely adopted (aside from Windows 95/98/2000). We would then lose the benefit of semantic versioning. Personally, I don’t recommend this.

 

Maybe if we want to build some excitement, we could add creative names to our releases. (I know my laptop is running Big Sur, but I have to actually look to see what number it is.) Maybe we name them after animals, colors, or international landmarks.

 

JimH

 

-- 

Jim Helwig

University of Wisconsin School of Medicine and Public Health Central IT

Application Development Manager

pronouns:he/him/his

--
You received this message because you are subscribed to the Google Groups "uPortal Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-user...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/CAJ_1GkQqj98Jdfpg-v2zZvWSJDsc3AYhDnEuN3-HABSYwyJyBw%40mail.gmail.com.

[Jonathan Tran]

- How often is too often for most institutions?

We do at least one update to production once a (calendar) quarter, so we might be able to get a patch in.
Minor/major releases would be a once a year thing as it requires time to get things sorted.

- What bandwidth do developers have to cut the releases?

With some guidance and a schedule, I think more releases can happen as well.

- Should effort go into the latest release or do we want to make it easier for implementers to stick to a particular feature release and only pick up patches?

The former. Our team wouldn't have the bandwidth to maintain a "rel-patches" branch and the artifacts that come with it.

- Does Semantic Versioning still work?

I believe it does. It helps sandbox the impact of changes and signals to adopters what to expect when updating to the next patch/minor/major release.

- Should we change our major number (e.g. 5) to the current year?

I'm not a fan of of year-numbered version numbers. My recent experience with this is Home Assistant [1] where they do monthly releases and version them as YYYY.mm.xx where xx is their patch releases to address issues that appear after the major release. I feel that switching to a year-based version number would break semantic versioning.

If we want to generate buzz like Jim suggested, we could look how Ubuntu names their releases (adjective animal) [2] ;)

[1] https://www.home-assistant.io
[2] https://en.wikipedia.org/wiki/Ubuntu_version_history

[Julien Gribonvald]

Hi,

So my thougths:

- keep the sementic way and don't make a major release for nearly nothing. A lot of French Universities are going away from projects that make a release too often, they don't have resources to follow project ! As example CAS project is a mess as a new release is done each 3 month and a version live 6 month, following versions cause a lot of works as each version provide too much change and a new qualification should be made each time ! Shibboleth seems to go on this way (mayeb with less bad change)  => they look at keycloack. Also these universities have some versions projects that they keep for 4 years, and even more. On an other way if we do too much major release, peoples will request LTS versions, so much effort to maintain versions !

I my mind uPortal have the maturity that don't need a such way, even more we should switch to last spring version before to change the way of doing release, spring will impose to do much frequently some release.

We can show the project activity by doing release (each month ?) on all uPortal eco-system apps, so it will make something like a "circle of releasing" with all apps.

- releasing a uportal version per quarter could be good but no more frequently, and in the sementic way !

- uPortal-start was build to make easy the uPortal deployment and to follow versions, so for me we should make all effort to keep this way and to help deployers to follow each versions (It's a requirement alse peoples will go away). But maybe something is missing, in the uPortal-start maybe we should tag/provide a migration version step (when needed) to purpose a specific migration script/command/conf to migrate from previous version to new one, and after removing it to avoid to keep old useless code.

- doing a current-year release is useless and don't provide anything interesting expect confusion on which version we should make effort for migration, peoples want to migrate easily and don't pass there time to upgrade. It's a wrong message for me. After if you want to show current year release, providing the page of versions history at the first place, it will be enougth ! Those who are thinking that an app version too small isn't a good one, they didn't look at the project history and surely don't watch at the project ! In my mind having a docker version for easy instant test would be more productive.

So to conclude, don't change anything expect maybe 2-4 sementic releases of uPortal per year, and doing a planning on a "circle of releasing" with all uPortal eco-system apps until migrated to last spring version (we will need to review this after this step).

Thanks

Julien Gribonvald

[Benito Gonzalez]

On the major version number as a year:

We can have the major version number as year and still follow semantic versioning -- these are not mutually exclusive. Changes that break backwards compatibility are ONLY released annual. Still, it sounds like a majority would rather not adopt this approach.

On too many releases:

I understand the issue with CAS and other projects releasing too often. Thus the motivator for this discussion. I strongly believe a predictable release schedule will allow institutions greater ability to plan upgrades. I'm actually leaning toward bi-annual feature releases with major releases semi-annually. Patch releases would be cut as needed to keep the project secure and functional.

Sounds like a plan is forming.

Portlets? They change so rarely that a plan doesn't make sense. Release as needed.

Web components? Change often and the underlying dependencies also change often. Again, release as needed.

-bjagg

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/ce5d5e97-c64c-588e-d380-27e90b5848e6%40recia.fr.

[Benito Gonzalez]

Also, if you don't know who can cut a release, here is the list:

https://github.com/uPortal-Project/uPortal/blob/master/docs/COMMITTERS.md

If you are a committer that is trying to cut a release and needs help with the process:

1. uPortal -- https://github.com/uPortal-Project/uPortal/blob/master/docs/developer/other/RELEASE.md

2. portlets -- https://github.com/uPortal-Project/uportal-project.github.io/blob/1211323da06b4c412ee6c7b7f043de4e81af1653/developer/maven-release-process.md

3. web components -- https://github.com/uPortal-Project/uPortal-web-components/blob/1dfd1788a9f935e274b026e69ad95266bbcf24b2/docs/en/developer/RELEASE.md

If you are a committer and lack permissions or need help, contact Jim H. or me.

-bjagg

[Julien Gribonvald]

For portlets I'm agree it doesn't change a lot, expect on dependencies, so releasing 2-3 times at least per year a patch/minor versions make sense for me and provide activity on projects.

So I'm nearly on the same point of view but for all uPortal eco-system projects for this part: Patch releases would be cut as needed/regularly to keep the project secure and functional. It's the minimum that we can plan easily, and we can cut release without doubt/talks at a defined calendar.

After on a release roadmap, I would prefer to have patch/minor version than major. Having a major version say that there is a breaking change, and it means that we may have a lot of time to pass on the project to qualify/test the new version. And so if you make too often a breaking change peoples won't follow each version (on my context I won't be able to justify easily to follow each breaking change even if it appears only one time per year) and so if we miss several major release we may diverge without possibility to continue on the current deployement (so restarting from source would be needed). Since version 5, the best argument on uPortal was that we can follow easily all versions as we didn't get breaking change ! After all depends on the level of the breaking change, if that don't change anything into the project deployment and that the migration is really easy it's OK !

Finally having a release calendar to cut minor/patch version frequently (even every month) I'm agree and it's important for security, but for a breaking change it's complicated to say, my only whish would be that It shouldn't be too difficult to migrate.

Thanks

Julien Gribonvald

[bgonzalez]

I completely empathize with your point. Breaking changes are disruptive.

We are not expecting HUGE changes like the difference between uPortal 4 and uPortal 5. If we look at a 2 year major release cycle, there should be time to make upgrading easier. I envision that uPortal-start would still be used to deploy uPortal 6. 

It's also important to start cataloguing what we consider breaking changes. Are these breaking changes?

- new db table

- new db table column

- renamed table (looking at you, Announcements Portlet!)

- renamed properties key

- change on what is acceptable for a properties value (a non-backwards compatible change was needed for some keys in 5.6/5.7)

- Moving packages around

- Removing deprecated code

[Julien Gribonvald]

Hi Benito,

You're rigth about listing what is a real breaking change. The semver doc https://semver.org/ is more an abstraction.

I'm not sure about your list, but an example would be on changing a way of doing a thing, like moving from XSLT to a new UI system, or moving out from bootstrap (that will need to review all CSS of a custom theme), so it's more on removing something used.

For me adding a new thing is a feature that don't introduce a breaking change, expect if it change how things works without possibility to move back. So a breaking change provide a change on doing a thing that we had before.

Renaming a property can be a breaking change, but it's more a minor one, if we don't consider it as a BC we should give/provide a way to move to the new one without difficulty.

A deprecated code is not a breaking change if nothing use it in the core and we should add a warning log that prevent about removing it between 2 versions ( or time laps) before to remove it.

Julien Gribonvald

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/e18123d8-6323-4873-9fb1-c857defa722dn%40apereo.org.

[Benito Gonzalez]

This thread has existed for a while. If anyone else wants to join in, please do.

Let's start capturing this with some decisions for review and approval.

Thanks!

-bjagg

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/21d39a97-77c2-27c5-25a1-a0f8896d3ff3%40recia.fr.

[Andrey Postoyanets]

Greetings Everyone,

 

Hard to believe that half of the summer is gone…

 

Benito / Julien,

 

You have been nailing many points, as I personally feel. Thank you for your excellent ideas and discussion!

 

My personal 2 cents… When I look at the state of a specific open-source project for the purpose of evaluating it, the level of activity matters to me more than the version numbering.

(Yes, I would probably stay away from something that is numbered v. 0.71. :)

It does not really matter to me if it is version 5 or 71 or 17. As long as I see that the project is active (and not appeared yesterday, that’d a good sign.

Apache Httpd has been on the 2.4 release for almost 10 years – but I actively use it  :) Same with Tomcat (v. 6, 7, 8, 9…:)

At the same time, I can understand why the “commercial” software might benefit more from the year-based numbering.

 

Renaming tables or moving packages around might be good examples of breaking changes. But again, I’d mean uPortal itself, not the portlets.  Ideally, such updates in portlets should also be deferred until major uPortal releases.

 

In general, a 2-year cycle for major releases sounds reasonable. Yearly releases might be too much for us specifically (public colleges) to handle – with shrinking budgets, less and less available time, more emphasis on testing and security than on the features, etc.

 

Also, we need to consider Java version life cycles:) Maybe I’m looking too far ahead right now, but we could not run our uPortal 4 on Java 8 – only Java7.

So if a specific version of Java goes “out of life”, this might trigger a need for a new “major” uPortal release. Despite all the backwards compatibility promises with Java, this is not completely true.

 

Cheers,

Andrey Postoyanets

CUNY / Brooklyn College

 

From: uporta...@apereo.org <uporta...@apereo.org> On Behalf Of Benito Gonzalez
Sent: Thursday, July 15, 2021 12:27 PM
To: Julien Gribonvald <julien.g...@recia.fr>
Cc: uPortal Community <uporta...@apereo.org>
Subject: Re: [uportal-user] Poll/Discussion: frequency of uPortal releases

 

CAUTION: This email is from outside BC, so examine it closely before opening attachments or clicking on links

 

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/CAJ_1GkR3JgazdZzw1tg7Eno2OVppUbDq1Qcyj5CT_BS%3D057e5Q%40mail.gmail.com.

[Benito Gonzalez]

Thanks for the feedback!

-bjagg

[Julien Gribonvald]

Thanks Andrey,

you provided a really good argument about java version, we may follow some java LTS versions for releasing a new version, so at least every 4 years. After we could make intermediate major version, like that every 2 years we can have a major version. It's a plan that we can follow. After we can have a major/intermediate version yearly or every 6 month to provide new feature or breaking points, but in my mind we should keep at least a version supported ( only ?) with patch for security fix/libraries update for 2 years and we provide a specific name for such versions and other major version get a yearly/semester/quarter name ?

So in that way we can have a major version with a LTS of 2 years, and we get intermediate major version that will be supported until next release. It means also that we have to provide migration guideline between LTS version, all intermediate versions won't have a high level of support as they will be on something like a "continuous development".

What do you think about this plan ?

Julien Gribonvald

[Benito Gonzalez]

Sounds like a good plan!

-bjagg