uPortal-start: releases? Or articulate why no releases?
Andrew Petro
Otherwise it fails a smell test: one of the first things I look at to see if something seems like it might be any good on GitHub is whether it has releases. No releases? It's probably not being maintained.
This relates to but is not quite the same as our recent discussion of what branches uPortal-start should have and what releases of uPortal it ought to rely upon.
(Context: following up on an action item I took in the most recent uPortal-steering meeting , I think part of a more general theme of tightening up loose ends going into Open Apereo.)
I'd like to give this a chance for discussion and perspectives. Nonetheless where I think this is going is uPortal-start is intentionally not going to be cutting releases and we just need to update the README to be clearer that and why this is the case. I'm willing to take a stab at a Pull Request adding that articulation, once it becomes clear here on uportal-dev@ that that's where this is going.
As ever,
Andrew
Julien Gribonvald
Thanks Andrew,
In my point of view uPortal-start is only a CLI to deploy
uPortal eco-system apps, so cutting a release per new uPortal
release don't make sense for me. Also when I watch on a github
project I'm not watching only on release but on the last update
of sources (to see if there is a good activity) + commit
frequency and if there are several contributors. Also I go more
easily on master branch when developping than on release, expect
for some case (big projects where a stability is needed when I
won't be able or have time to look for patching/ purpose bug
fix).
After, to explain my process of my work on uPortal deployment:
Until I stay in development process I won't take care of a release on uPortal-Start as I will try always to be on the last version on master, so in this case the important thing for me is to keep updated dependencies version when a new release is created on theses importants dependencies (of uPortal and portlets).
For the case when I'm in production with a version I will need only to keep updated for security path but I won't go on new uPortal version without a qualification phase that will take some times (so no more than one time per year). So in this case I will watch on github which last commit of the uPortal-start I will use, and if there is a compatibility problem from different uPortal version I will be happy to see a specific branch for my uPortal major version (it's if it makes 2 years that I didn't updated anything).
So for me the important thing to say is : "uPortal-start is
only a CLI to deploy an uPortal version with uPortal eco-system
apps, so it don't need a release on each new release of all
these apps, so just find the commit that will suit your needs
!", but the important thing is to be efficient on version change
of dependencies and we should be sure that an update of a
version won't break any compatibility with all other apps.
Hoping that was understandable for the discussion !
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
wrt "just find the commit that will suit your needs"
If there's a commit that will suit multiple adopters' needs, well, that starts to sound like a release, doesn't it?
It's hard to find the limit of releasing in this case, as if
you publish a new release of a portlet you will also need to cut
a new release of uPortal-start ?
In my point of view having only a branch per major release would be suffisant and maybe it's too much for some cases. Having a release process on uPortal-start take a sence only if a new feature appear on the uPortal-start and that need to cut the current branch update. In my mind when updating only the uPortal version, even on a major version, which doesn't need a "featured update" / "breaking change" on uPortal-start it won't need a uPortal-start release.
Julien
Julien Gribonvald
Benito J. Gonzalez
Three ideas strike me on this topic.
No releases.
An implementor starts at some point and starts tweaking for their
environment. They run some upstream merges to get updates. What did they
pick up? Could be anything. Why should the upgrade? Maybe their heard of
something added recently from this mailing list. Did they spend some
time figuring out their last pull and how upstream master deviated?
Sync'ed releases with uPortal
An implementors wants the latest version of uPortal. They upgrade
uPortal-start to pick it up. Are there releases notes to share what new
CLI features have been added since the previous uPortal version?
Separate releases for uPortal-start
An implementor is tooling along with uPortal and portlet upgrades. They
have a need for a new CLI tool or heard of a new one from the community.
They look at the release notes and find it's been included in a newer
release?
I lean toward separate releases where they follow SemVer (Semantic
Versioning) for the features in that project. Chores of keeping the
latest version of projects would not even rise to "bug fix" releases. I
suggest we note in the readme that the project follows SemVer for the
tooling, but does not cut releases for version upgrades on the projects.
Just thinking out loud,
-bjagg
--
Benito J. Gonzalez
Senior Software Developer
Unicon, Inc.
Voice: 480.558.2360
Text: 209.777.2754
Email: bgon...@unicon.net
GitHub: bjagg
GitLab: bjagg
BitBucket: bjagg
Christian Murphy
jmt
Christian Murphy
--
Benito J. Gonzalez
it is more that just captured versions of other modules. Versioning will
be helpful in determining that a deployer is missing some cool Gradle task.
Hope this helps,
-bjagg
> Text: 209.777.2754 <tel:(209)%20777-2754>
> Email: bgon...@unicon.net <mailto:bgon...@unicon.net>
> GitLab: bjagg
> BitBucket: bjagg
>
> --
> 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
> 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