how to follow uPortal upgrades with low means

[Julien Gribonvald]

Hi folks,

I re-run on the dev list an exchange about some thougths on how to find a way to have lower cost for small organizations on uPortal upgrades and more to be able to follow uPortal version more easily.

I hope that the community will join the discussion to give a feeling and what they would like to see or where to go.

Here is my first tought (only a thought) and I hope that everyone will reply/provide their point of view.

Since several weeks I thought about one thing that could help on decisions ;-). 

-> It's only a thougth and somes can provide a better one.

This thought is more about a feedback that I have in the ESUP community, I think it may be great to provide a LTS (Long Time Support) on chosen uPortal release.

Why I purpose that, it's simple, organizations with low means will go more easily on such release and more if they have a view of their "stillness"/"serenity" (which one ?) like "when will I need to update this project for my organization ?", I heard several times "Your uPortal is complicated to maintain as you need to go on a new version each 2 years, and sometime when you begin with a version 2-3 month after the version is outdated...". It's difficult to hear that but it's the point of view from services directors, and generally it's because they doesn't have a real competent engineer in uPortal technologies (only young engineer as their have a big turnover or system engineer for the main part...), so it's only a problem on available skills but...

Also a LTS support will avoid comparison against internal development !

After for CONS I'm agree this will need more effort on supporting old development, and to be able to provide new LTS release...

Maybe I launched a discussion of kind "A fly in the ointment" (in French "un pavé dans la marre" / literal translation "throw a paver in the pond"), but it's to share some thoughts and don't be afraid to cut this thought quickly ;-)

So any thoughts ?

Best regards,

--
Julien Gribonvald

[Christian Murphy]

Hey Julien!

> how to find a way to have lower cost for small organizations on uPortal upgrades and more to be able to follow uPortal version more easily.

Lowering the cost of upgrading is primary goal of uPortal 5, and we have made good progress.

Just last week, working with Foothill, we were able to upgrade from uPortal 5.0.6 to 5.1.0 in less than 15 minutes.

The Gradle build system, the separation between uPortal core and uPortal start, semantic versioning, etc.

have made the upgrade process significantly easier than with previous releases (<=4.3.x).

> uPortal is complicated to maintain as you need to go on a new version each 2 years, and sometime when you begin with a version 2-3 month after the version is outdated

That's insightful and similar to other feedback we've heard from other folks running uPortal 3 and 4.

Digging more into the root cause, based off previous discussions, it seems that the differences between uPortal versions have been too large to manage.

The migrating past the breaking changes required significant investment, and that made folks nervous about upgrading.

That is part of the motivation behind the faster release cycle and semantic versioning in uPortal 5+.

Minor and patch releases are as simple as changing the version number.

Major releases will become will be smaller, only a few breaking changes, which will take less time to migrate across.

> This thought is more about a feedback that I have in the ESUP community, I think it may be great to provide a LTS (Long Time Support) on chosen uPortal release.

I'm not sure LTS would address the problems you described.

LTS releases allow adopters to avoid migrating to new versions for longer, increasing the amount of effort needed when they do upgrade.

It seems like LTS could cause the opposite effect as intended, making upgrades more frustrating instead of less.

> they doesn't have a real competent engineer in uPortal technologies

Part of the improving the upgrade process is lowering the amount of domain knowledge needed to work with uPortal.

By leveraging more of Spring and Gradle we are making the uPortal core project more approachable to Java developers.

By automatically generating a configured tomcat and by leveraging the Docker ecosystem we are making the uPortal-start project more approachable to Operations teams and IT specialists.

We've made great process toward making the process easier, we will continue to work toward improving the process.

Best Regards,

Christian Murphy

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/uportal-dev/.

[Andrew Petro]

Hi Julien,

I think I hear you. Long-term-support for long values of "long-term" is one way to reduce upgrade costs as actually realized by a given institution. Only upgrade every 4 years or so and otherwise accept little fix patches and hey maybe your ammortized upgrade costs are low.

I don't think long-term-support is the best model going forward. Maybe five years ago. Today, the world has moved on. Continual upgrades with really low upgrade costs are the way to go. We don't need to support old versions longer. We need to make it really, really feasible to keep up with new versions and then only "support" very recent versions.

MyUW upgraded from Jenkins1 to Jenkins2 a while back. Major release. Took a couple hours.

Jenkins has Long Term Support releases. Every 12 weeks. To provide a more stable alternative to their weekly releases.

The "Shared Tools" team in DoIT upgrades GitLab every couple weeks or so.

uPortal needs to feel like evergreen, polished software products. Everyone upgrades no-less-frequently than quarterly, and typically more frequently than that, because it's very feasible, low cost, easy, and picks up worthwhile progress.

I hear you on the desire for Long Term Support releases. I think uPortal will be doing it right when there's little desire for Long Term Support releases because adopters are comfortable keeping up with upgrades.

As ever,

Andrew

[Julien Gribonvald]

Thanks Christian and Andrew,

I know that uP 5 go on this way, but I think their should be something that show it clearly (for decision maker / directors), that's why I purposed a system ala LTS. But I understand it's difficult to support a such model, I think we must find a way that will confort the low cost on "continual" upgrades ! And more to show that it works, and document how to do it easily ! Somes institution doesn't have an automated deployment service ;-)

Andrew you've got my idea ;)

After the LTS support was an example, but in my mind we need a way to show clearly the long time support on some important/core features and that uPortal have a line of conduct to provide an easy and fast way to follow each upgrades without having big development competences.

Thanks,

Julien

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/uportal-dev/.

--
Julien Gribonvald