Hi,
2014-06-05 7:52 GMT+02:00 Oschwald Robert <robertoschw...@googlemail.com>: > Am 05.06.2014 um 03:05 schrieb Misagh Moayyed <mmoay...@unicon.net>: > > I am not sure if 5.0 is the immediate subsequent release after, 4.1, is > it? Or perhaps my more pertinent question might be “Should it be?”? I’d > suggest that we incrementally march towards 5 while staying on the 4.x > release line. Incremental small changes as much as we can, allow us to make > quick progress, and release as often as we can, and also allow folks to > upgrade easier. Jumping directly from 4.1 to 5 seems like a pretty big move > and we could still do a lot of good work in between that don’t impact the > codebase as a whole. > > > +1 It was not meant that we should immediately move towards 5.0. I think > from a roadmap point of view, the protocol changes are a candidate for 5.0 > (which is to be released somewhere in the feature - until then, we work on > 4.x changes). > Jérôme: +1 5.0, 4.2,...: I think we'll see where it fits best after comprehensive discussions... > - Moving the CAS protocol off the Jasig website and onto the GH > pages docs site: I had a lot of trouble keeping to the syntax of the > WYSIWYG editor, which truly was necessary work. So in the spirit of > synchronicity, I’d like to include the protocol doc in the documentation > somewhere, so that it stays with the version of the CAS software that is > released. > > > +1 > > Jérôme: +1 If it makes things easier... > - I have been thinking about, (and have discussed this idea with a > few other peers at Apereo 2014) that perhaps we should be moving off of > JIRA and over to Github Issues. We are not really taking full advantage of > JIRA for what it does best, and are simply treating it as a todo list. > Using Github issues, allows us to track issues in relevance to the PR > easier, as they are kept near the code and the docs, and also it’s easier > for users to submit those issues because they don’t need to create a > separate account. We could just about do everything that we currently do in > terms of release management and milestones with Github too so I really > don’t see the point in keeping to a separate system. I’d be glad also, to > take on the responsibility of transferring the existing JIRA issues over to > Github and we could take it from there… > > > big +1! Linking PRs/commits to the tickets is a big advantage. > Jérôme: -1 I really think that JIRA is a lot more powerful : you can assign to someone, you have "Status", "Affect version", "Fix version"... You can search on fields, create the release notes... I don't think you have all these useful features in the Github issues. > > - In addition to dropping/deprecating/moving the uber-webapp and > the jboss cache modules, I’d also like to nominate the JPATicketRegistry > and relevant components for deprecation. The feature hasn’t really received > any attention for a while, and no longer seems like a suitable option for > HA deployments and I have seen more than a few CAS deployments that have > had trouble tuning and configuring the registry to really perform. We could > swap in much better and more lightweight alternatives that I’d be happy to > discuss details for their merit. > > > -1 > Not everyone uses CAS in a HA environment. > I think JPA is currently the most used registry, isn’t it? System > Complexity is the lowest when using JPA, and is self-contained in CAS when > using any in-memory Java backend. > Not to forget RememberMe issues with some of the other existing registry > implementations on application restart. > Jérôme: I thought that the JPATicketRegistry was widely used, didn't it? > > Best regards, -- Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
