Re:[uportal-dev] [uportal-user] Courses Portlet pull request merged
(moving over to dev to chat quickly about minor release of courses portlet) Nice work Mike team! I'm sure people are very excited for these enhancements. Since there was a model change it would be good to cut a minor release. What say the people? Tim Levett tim.levettATwisc.edu MyUW-Infrastructure From: bounce-37385619-70367...@lists.wisc.edu bounce-37385619-70367...@lists.wisc.edu on behalf of Mike Farnham mrfarn...@wisc.edu Sent: Friday, October 17, 2014 7:05 PM To: uportal-u...@lists.jasig.org Subject: [uportal-user] Courses Portlet pull request merged The University of Wisconsin-Madison has contributed back the extensive changes we have added to the Courses Portlet. I do say extensive because the commit includes 153 changed files with 8,335 additions and 714 deletions. We apologize for the pig through the python approach. We have did update the model. We did our best to insure the changes work with the existing code. We have included mock data for the changes we've made so you can run the code out-of-the-box, in uPortal. I think most interest has been peaked by the Class Schedule Grid which relies heavily on the jquery.timetable.js project. best regards, Mike -- Mike Farnham Information Systems Specialist DoIT Academic Technology University of Wisconsin-Madison (608) 262-4210 https://www.doit.wisc.edu/about/organization/academic-technology/ --- You are currently subscribed to uportal-u...@lists.jasig.org as: tim.lev...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] sticky profile selection
There may well be interesting future use cases around profile selection. Or perhaps we will enter a lovely future in which there's just one responsive profile to handle all comers. I think that's where MyUW is trying to get with its forked-from-respondr-responsive-theme : even the amount of stickiness complexity here is just a transitional feature to gently migrate folks from Universality to Bucky. At the least I'll take a shot at articulating how an adopter would achieve what you describe by plugging in to the extension points this solution exposes. Kind regards, Andrew On Sun, Oct 19, 2014 at 3:16 PM, Anthony Colebourne anthony.colebou...@manchester.ac.uk wrote: Hi, I was wondering whether stickiness in this regard should be a build time or runtime choice? Might there be a use case where both might be required in a single uPortal instance? The only case I can think of is switching from a dedicated mobile theme to a desktop theme while using a mobile device. It's not the strongest case for needing runtime sickness choice, but if these one use-case then there might be others! The thought that came to mind was /Login?profile=buckysetDefault=true or /Login?profile=buckyoneTime=true -- Anthony. On 17/10/14 19:01, Andrew Petro wrote: uPortal developers, MyUW has a need to make ad-hoc profile selection (via profile=bucky on /Login) less hoc and more sticky-across-sessions. UP-4223 took a shot at this but didn't seem to work in MyUW. https://issues.jasig.org/browse/UP-4223 https://github.com/Jasig/uPortal/pull/416 Having looked into this a bit, I'd like to propose this alternative implementation of making profile selection sticky: http://apetro.ghost.io/sticky-profiles/ I'm close to working code implementing this design and intend to offer a Pull Request once it seems to be working locally. Feedback and design input welcome. Kind regards, Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: apetro.li...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [uportal-user] Courses Portlet pull request merged
I think that is consistent with semantic versioning, right? JimH On Oct 20, 2014, at 9:00 AM, Tim Levett tim.lev...@wisc.edu wrote: (moving over to dev to chat quickly about minor release of courses portlet) Nice work Mike team! I'm sure people are very excited for these enhancements. Since there was a model change it would be good to cut a minor release. What say the people? Tim Levett tim.levettATwisc.edu MyUW-Infrastructure From: bounce-37385619-70367...@lists.wisc.edu bounce-37385619-70367...@lists.wisc.edu on behalf of Mike Farnham mrfarn...@wisc.edu Sent: Friday, October 17, 2014 7:05 PM To: uportal-u...@lists.jasig.org Subject: [uportal-user] Courses Portlet pull request merged The University of Wisconsin-Madison has contributed back the extensive changes we have added to the Courses Portlet. I do say extensive because the commit includes 153 changed files with 8,335 additions and 714 deletions. We apologize for the pig through the python approach. We have did update the model. We did our best to insure the changes work with the existing code. We have included mock data for the changes we've made so you can run the code out-of-the-box, in uPortal. I think most interest has been peaked by the Class Schedule Grid which relies heavily on the jquery.timetable.js project. best regards, Mike -- Mike Farnham Information Systems Specialist DoIT Academic Technology University of Wisconsin-Madison (608) 262-4210 https://www.doit.wisc.edu/about/organization/academic-technology/ --- You are currently subscribed to uportal-u...@lists.jasig.org as: tim.lev...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jim.hel...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev smime.p7s Description: S/MIME cryptographic signature
Re: [uportal-dev] [uportal-user] Courses Portlet pull request merged
I think a minor version change would be appropriate. If I remember correctly we had to change it a bit to work with Banner at OU, so we might need to figure that out again with this release. Thank you guys for your hard work and contributing this back to the community. I'll be excited to see how grid schedules look in MySAIL. Aaron On Mon, Oct 20, 2014 at 10:00 AM, Tim Levett tim.lev...@wisc.edu wrote: (moving over to dev to chat quickly about minor release of courses portlet) Nice work Mike team! I'm sure people are very excited for these enhancements. Since there was a model change it would be good to cut a minor release. What say the people? Tim Levett tim.levettATwisc.edu MyUW-Infrastructure From: bounce-37385619-70367...@lists.wisc.edu bounce-37385619-70367...@lists.wisc.edu on behalf of Mike Farnham mrfarn...@wisc.edu Sent: Friday, October 17, 2014 7:05 PM To: uportal-u...@lists.jasig.org Subject: [uportal-user] Courses Portlet pull request merged The University of Wisconsin-Madison has contributed back the extensive changes we have added to the Courses Portlet. I do say extensive because the commit includes 153 changed files with 8,335 additions and 714 deletions. We apologize for the pig through the python approach. We have did update the model. We did our best to insure the changes work with the existing code. We have included mock data for the changes we've made so you can run the code out-of-the-box, in uPortal. I think most interest has been peaked by the Class Schedule Grid which relies heavily on the jquery.timetable.js project. best regards, Mike -- Mike Farnham Information Systems Specialist DoIT Academic Technology University of Wisconsin-Madison (608) 262-4210 https://www.doit.wisc.edu/about/organization/academic-technology/ --- You are currently subscribed to uportal-u...@lists.jasig.org as: tim.lev...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: asgr...@oakland.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Aaron Grant Senior Applications Architect Oakland University - UTS http://oakland.edu/uts -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [uportal-user] Courses Portlet pull request merged
Developers, Under Semantic Versioning, whether a given changeset gives rise to a major or minor version bump depends whether the changes break an existing API. If they do, that¹s a Major release, not a minor release. If they break no APIs and only add features within existing APIs, great, that¹s a minor release. Eyeballing the changeset, looks like Semantic Versioning would class this API-breaking and thus a Major version bump. https://github.com/Jasig/CoursesPortlet/pull/14/files Just on quick skim: * public class CourseRequirementWrapper methods disappeared * API defined in course-catalog.xsd changed in breaking ways Note that Semantic Versioning isn¹t about value judgements about change sets. Changing APIs to give rise to a new Major version isn¹t good or bad, it just is, and Semantic Versioning communicates that that amount of change has happened. This is a big changeset and it technically breaks APIs. Call it, modulo any cleanup and additional feature merges between now and release, Courses Portlet v. 2.0, and celebrate the step forward for the open source product. Kind regards, Andrew On 10/20/14, 10:11 AM, Jim Helwig jim.hel...@wisc.edu wrote: I think that is consistent with semantic versioning, right? JimH On Oct 20, 2014, at 9:00 AM, Tim Levett tim.lev...@wisc.edu wrote: (moving over to dev to chat quickly about minor release of courses portlet) Nice work Mike team! I'm sure people are very excited for these enhancements. Since there was a model change it would be good to cut a minor release. What say the people? Tim Levett tim.levettATwisc.edu MyUW-Infrastructure From: bounce-37385619-70367...@lists.wisc.edu bounce-37385619-70367...@lists.wisc.edu on behalf of Mike Farnham mrfarn...@wisc.edu Sent: Friday, October 17, 2014 7:05 PM To: uportal-u...@lists.jasig.org Subject: [uportal-user] Courses Portlet pull request merged The University of Wisconsin-Madison has contributed back the extensive changes we have added to the Courses Portlet. I do say extensive because the commit includes 153 changed files with 8,335 additions and 714 deletions. We apologize for the pig through the python approach. We have did update the model. We did our best to insure the changes work with the existing code. We have included mock data for the changes we've made so you can run the code out-of-the-box, in uPortal. I think most interest has been peaked by the Class Schedule Grid which relies heavily on the jquery.timetable.js project. best regards, Mike -- Mike Farnham Information Systems Specialist DoIT Academic Technology University of Wisconsin-Madison (608) 262-4210 https://www.doit.wisc.edu/about/organization/academic-technology/ --- You are currently subscribed to uportal-u...@lists.jasig.org as: tim.lev...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jim.hel...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [uportal-user] Courses Portlet pull request merged
Call it … Courses Portlet v. 2.0, and celebrate the step forward for the open source product. And update the README to state clearly that the project uses Semantic Versioning. It’s not clear that it now does ― if it’s not using Semantic Versioning and is instead using the current uPortal release strategy, well, then calling this next release a minor release is within the current uPortal release strategy (inflicts some pain on upgrade but is not revolutionary change). https://wiki.jasig.org/display/UPC/Release+Strategy http://semver.org/ I’d strongly favor adopting Semantic Versioning in that portlet (and everywhere else), of course. Kind regards, Andrew On 10/20/14, 11:01 AM, Andrew Petro andrew.pe...@wisc.edu wrote: Developers, Under Semantic Versioning, whether a given changeset gives rise to a major or minor version bump depends whether the changes break an existing API. If they do, that¹s a Major release, not a minor release. If they break no APIs and only add features within existing APIs, great, that¹s a minor release. Eyeballing the changeset, looks like Semantic Versioning would class this API-breaking and thus a Major version bump. https://github.com/Jasig/CoursesPortlet/pull/14/files Just on quick skim: * public class CourseRequirementWrapper methods disappeared * API defined in course-catalog.xsd changed in breaking ways Note that Semantic Versioning isn¹t about value judgements about change sets. Changing APIs to give rise to a new Major version isn¹t good or bad, it just is, and Semantic Versioning communicates that that amount of change has happened. This is a big changeset and it technically breaks APIs. Call it, modulo any cleanup and additional feature merges between now and release, Courses Portlet v. 2.0, and celebrate the step forward for the open source product. Kind regards, Andrew On 10/20/14, 10:11 AM, Jim Helwig jim.hel...@wisc.edu wrote: I think that is consistent with semantic versioning, right? JimH On Oct 20, 2014, at 9:00 AM, Tim Levett tim.lev...@wisc.edu wrote: (moving over to dev to chat quickly about minor release of courses portlet) Nice work Mike team! I'm sure people are very excited for these enhancements. Since there was a model change it would be good to cut a minor release. What say the people? Tim Levett tim.levettATwisc.edu MyUW-Infrastructure From: bounce-37385619-70367...@lists.wisc.edu bounce-37385619-70367...@lists.wisc.edu on behalf of Mike Farnham mrfarn...@wisc.edu Sent: Friday, October 17, 2014 7:05 PM To: uportal-u...@lists.jasig.org Subject: [uportal-user] Courses Portlet pull request merged The University of Wisconsin-Madison has contributed back the extensive changes we have added to the Courses Portlet. I do say extensive because the commit includes 153 changed files with 8,335 additions and 714 deletions. We apologize for the pig through the python approach. We have did update the model. We did our best to insure the changes work with the existing code. We have included mock data for the changes we've made so you can run the code out-of-the-box, in uPortal. I think most interest has been peaked by the Class Schedule Grid which relies heavily on the jquery.timetable.js project. best regards, Mike -- Mike Farnham Information Systems Specialist DoIT Academic Technology University of Wisconsin-Madison (608) 262-4210 https://www.doit.wisc.edu/about/organization/academic-technology/ --- You are currently subscribed to uportal-u...@lists.jasig.org as: tim.lev...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jim.hel...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: andrew.pe...@wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Release 4.1.2?
Folks, It’s been almost 2 months since the release of 4.1.1. There have been 21 non-merge commits to eel-4-1-patches sense then: https://github.com/Jasig/uPortal/commits/rel-4-1-patches (Also a review of master may yield additional commits that meet the patch release criteria.) Is it a good time to work on a release? Is anyone working on something that will go into the 4.1.x line? drew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Semantic Versioning : we should do it
James, JW I see [API breaking changes hanging out on a feature branch where other changes might in turn break them] as being a risk and a maintenance hassle Yes. *Breaking APIs inflicts hassle* at least one way or another. Either these breaking API changes are increasing the cost of non-API-breaking-changes, or non-API-breaking changes are potentially increasing the cost of eventually merging the API-breaking changes. *Moving API breaking changes into feature branches moves that hassle away from the center of the stage.* JW I like master having the latest of everything integrated into it. Sure. But I like master having *the latest **non-API-breaking** code*, since that's what I most care about for MyUW. It's also what I expect a *typical adopter* and a typical new adopter to be most interested in working from. So long as the project is doing Major releases regularly (and so API-breaking changes do make it into Master, it's just they do so only every 18 months or so), *hanging out on the non-API-breaking changes off of the latest Minor release is going to be adequate to most adopters' needs, the right place on the stability-features tradeoff curve.* It's a matter of being less casual about breaking APIs. There'd be nothing to stop a next_version branch representing the combination of those API-breaking feature branches, so as to combine their maintenance, if there's a real efficiency to be had there. However. I suspect that in practice this is less of a problem than one might think: While `master` is marching towards the next Minor release **APIs are not being broken** and so those *changes on `master` should not break the API-breaking features that are hanging out on feature branches.* So it should normally true that *API-breaking Feature branches continue to merge cleanly onto master* for the up to 18 months before it's time to merge them to master and cut another Major release. If they don't,* it's better to have that hassle in the feature branch that is about making an API-breaking change than it is to have that hassle dragging on non-API-breaking enhancements to the current released uPortal.* To the extent that there are multiple proposals to break APIs in different, non-compatible ways, well, that's certainly a problem that will need hashed out and resolved. We could detect that sooner with a `next_version` branch representing the union of these API breaking changes slated for the next release, but I suspect that deferring dealing with that until when we try to merge it all together for the next Major release would be fine in practice too. JW adopters having to pick and choose feature branches Eh. To the extent that these API-breaking-changes are so compelling that they're being adopted in production by multiple adopters and that their maintenance is a problem, that's evidence that it's time to cut that Major release and ship those changes and embrace, well, really maintaining that product. *I think we should optimize for adopters adopting released code, not for adopters adopting un-released code.* I don't see adopters having to grab these API-breaking feature branches so very often. They can not do that and *pick them up at the next regular Major release.* Or we could get to good enough APIs such that the compelling features that adopters want can be implemented in changesets that don't break APIs, even external projects written to stable APIs. * If uPortal aspires to be a Platform, then it needs to have APIs that are good enough that they can cruise for 18 months without urgently needing breaking. *Having stable APIs to which one can write compelling things is part of what makes something a platform. JW If we are truly doing something toward 'moving the decimal', then master should remain the latest and greatest of all accepted changes and we selectively back-port feature additions into the rel-4-x-patches like we used to with the 4.0.x line and periodically release minor versions. Sure. Supposing uPortal adopts semantic versioning for a uPortal 5.0.0 release (cleanest example), could go with * 5.0-patches : Bugfixes (that don't break APIs) on uPortal 5.0.0. Cuts 5.0.1, 5.0.2, 5.0.3... * 5-patches : Non-API-breaking enhancements on uPortal 5.0.0. Cuts 5.1, 5.2, 5.3, ... . Includes bugfixes from 5.0-patches. * master : API breaking changes marching towards uPortal 6.0.0; Includes bugfixes from 5-patches. I don't see this as ideal for a couple reasons. One is that it makes API breaking changes central and the norm by using `master` for this. Another is that it guarantees maximum tedious effort in the shared burden of keeping master up-to-date. If I make a backwards-compatible change adding value to 5-patches, I suppose I'm supposed to also go figure out how to apply that change to `master` where the involved APIs may have changed. Sounds like friction in making a backwards-compatible change providing value to current adopters now. I'd prefer something more like
