Current Releases
- Some people are still on 2.x; the latest 2.x releases were aimed at helping people
- 3.0.x
- 3.1.x
- Traditionally, the third digit is a patch release; the second second digit is a feature/function releases
Future Release Discussion
Note: The following are simply proposed releases brainstormed by the 14 people present at the working session. The uPortal Steering Committee will be reviewing this information and coming up with a more official release road map.
- 3.2 (approx)
- New portlet manager (improved UI)
- Multi-profiles support (based on user agent, etc.)
- Mobile theme
- Bundled building block portlets (XSLT, WebProxy, RSS, Image, Applet, Announcements, News/Calendar, Maps, Dictionary, Search)
- 3.3 (approx)
- Pluto 2.0/JSR 286 (4 man weeks)
- New URL syntax (human readability, bookmarkablity)
- 3.4 (approx)
- Spring security
- Grouper, groups API
- Toro gateway replacement
- What would cause us to do a major shift in a release (a.k.a., uPortal 4.0)?
Discussion and notes
Java Open Source competitors
- Liferay/Sun - starting to see competition
- JBoss -
- Jetspeed - we have not seen a lot of competition in our higher ed space
All of these have JSR 286 support. This should be one of our highest priorities. This requires upgrading to Pluto 2.0. This is perhaps a few weeks of work, but would leave us with a portal that only renders portlets. To accommodate channels, there would be significant additional work. Supporting channels will continue to involve significant additional work. Recent posts to the lists indicate there are significant deployments of custom channels.
Balance putting effort into additional support for existing deployments (thus risking losing new customers) with focusing on JSR 286 support (at the expense of existing deployments). Continuing to support channels makes it difficult to use modern Java techniques. It also increases the ongoing testing burden.
Support for existing channels is significant.
Rewriting the Groups Manager and Permissions Manager UI would be a manageable.
We have to determine if we drop channel support forever or temporarily. Channels have access to the entire uPortal API whereas portlets do not. It would be significantly easier to drop channel support. Jetspeed dropped their custom API support. JBoss never had custom APIs. Liferay might have custom APIs. These other products had a published API that they specifically supported; we did not. uPortal channels call all sorts of uPortal APIs.
It does not seem unreasonable for us to drop support. The main question is one of time frame.
We already have replacements for the channels we ship with (except for Groups Manager). Our public recommendation on the mailing lists has been to use the latest version of uPortal and write portlets.
We could ship with libraries/APIs that allow you to leverage additional portal functionality (e.g., groups API) if you want to commit to uPortal.
To get JSR 286 support:
- basic core functionality
- Groups Manager replacement
- Consider permissions manager replacement
- Bundle other core portlets (XSLT, image, applet, RSS)
- Add extension API for groups, etc.
The uPortal Steering Committee and the Jasig Board need to weigh in on this decision.
Schools that use building block channels need to help look at the migration of those to the portlet equivalent.
There are portlets that use various portlet/uPortal bridge libraries. These will have to by synchronized and moved to using a standard, supported bridge.