You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2007/07/16 18:44:10 UTC
Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
CDoremus@hannaford.com wrote:
>
> I am very much against moving toward a 1.2.0 release. We should not get
> mired in a 1.2.x release cycle of a JSR-168 impl. We need to start
> moving toward jsr-286. The jsr-286 EG will be releasing a public draft
> soon that is feature complete. Torsten's work in the 286 branch has
> almost caught up with the draft spec. Both Exo and JBoss portal has
> preliminary (alpha/beta) jsr-286 releases. We should not be that far
> behind.
There's no reason why we can't do both. OS is about scratching your own
itch. If someone wants to work on 1.2.x, then go for it. If you want
to focus on 2.x, then by all means - do it! Shoot, if someone wanted to
dig up 1.0.x they are welcome to do that as well.
David
> /Craig
>
>
>
> *Elliot Metsger <em...@jhu.edu>*
>
> 07/16/2007 10:00 AM
> Please respond to
> pluto-dev@portals.apache.org
>
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> Re: [VOTE] Pluto 1.1.4 Release
>
>
>
>
>
>
>
>
> Looks like the changes snuck in between the 1.1.2 and 1.1.3 release with
> PLUTO-350 (r523130) - the relative URL provider. I'm thinking we could
> probably take it out, but I haven't taken a thorough look.
>
> Of course, since the change is out there with 1.1.3, 1.1.3 users who
> move to 1.1.5 will be broken.
>
> We could re-release this 1.1.4 candidate as a 1.2.0, and put a note on
> the website noting the 1.1.3 incompatibility. Or just release 1.1.5 and
> retract 1.1.3?
>
> Elliot
>
> David H. DeWolf wrote:
> > -1
> >
> > 1.1.3 and 1.1.4 should be backwards compatible (binary and runtime
> > compat). This looks to me like we introduced an incompatibility. In the
> > meantime, is there a workaround we can use in order to get 1.1.5
> > released without this incompatibility?
> >
> > This type of change can be added to 1.2.x BUT should be specifically
> > mentioned in an "upgrade" guide.
> >
> > David
> >
> > Charles Severance wrote:
> >> Elliot,
> >>
> >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the following:
> >>
> >>
> /Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128:
>
> >>
> org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider
>
> >> is not abstract and does not override abstract method
> >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
> >> class SakaiPortletURLProvider implements PortletURLProvider
> >>
> >> Has an API changed? I am happy to update Sakai, adding methods or
> >> whatever - let me know if this was an intentional change.
> >>
> >> /Chuck
> >>
> >>
>
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by Elliot Metsger <em...@jhu.edu>.
Sorry when I say "286 being released" I mean the approval of the JSR.
How does the timeframe for the approval of the 286 JSR drive the Pluto
release schedule?
Elliot
Elliot Metsger wrote:
>
>
> David H. DeWolf wrote:
>
>> My preference would be for all of us to hammer out a 1.2.x and then
>> move on, but given how slow we move sometimes, I can understand why
>> some people would like to jump straight to 286.
>
> What is the timeframe for 286 being released? I think it is going to
> take some amount of effort, perhaps non-trivial effort to "merge" what
> is in the 286 branch with all the fixes and features that we currently
> have in trunk. My (perhaps mistaken) assumption is that a 286 release
> would include all of the progress we've made in the 1.x line since the
> 286 branchpoint.
>
> I'm 100% for a 1.2 release but my concern is the timing of the release
> of 286, and when Pluto needs to be ready. Is the release of 286
> something that needs to drive the Pluto release schedule or is my
> concern misplaced?
>
> Elliot
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> My preference would be for
> all of us to hammer out a 1.2.x and then move on, but given how slow we
> move sometimes, I can understand why some people would like to jump
> straight to 286.
What is the timeframe for 286 being released? I think it is going to
take some amount of effort, perhaps non-trivial effort to "merge" what
is in the 286 branch with all the fixes and features that we currently
have in trunk. My (perhaps mistaken) assumption is that a 286 release
would include all of the progress we've made in the 1.x line since the
286 branchpoint.
I'm 100% for a 1.2 release but my concern is the timing of the release
of 286, and when Pluto needs to be ready. Is the release of 286
something that needs to drive the Pluto release schedule or is my
concern misplaced?
Elliot
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by "David H. DeWolf" <dd...@apache.org>.
Elliot Metsger wrote:
oremus@hannaford.com wrote:
>
>>> I am very much against moving toward a 1.2.0 release. We should not
>>> get mired in a 1.2.x release cycle of a JSR-168 impl. We need to
>>> start moving toward jsr-286. The jsr-286 EG will be releasing a
>>> public draft soon that is feature complete. Torsten's work in the 286
>>> branch has almost caught up with the draft spec. Both Exo and JBoss
>>> portal has preliminary (alpha/beta) jsr-286 releases. We should not
>>> be that far behind.
>
> When, assuming this is a goal, is a good time for 286 to get promoted to
> trunk? And if so, what is the best way to go about doing this?
> Backporting 286 patches from the branch back to trunk?
>
Whether in the trunk or not, I think adding Java5 Support (and generics)
to the 168 container is a good baby step towards 286. We had also
talked about adding jaxb bindings, etc. . .in 1.2.x. I'm very
interested in keeping this going, but am fine with it taking place in a
branch if that's the communities preference. My preference would be for
all of us to hammer out a 1.2.x and then move on, but given how slow we
move sometimes, I can understand why some people would like to jump
straight to 286.
David
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
>
>
> CDoremus@hannaford.com wrote:
>> I am very much against moving toward a 1.2.0 release. We should not
>> get mired in a 1.2.x release cycle of a JSR-168 impl. We need to start
>> moving toward jsr-286. The jsr-286 EG will be releasing a public draft
>> soon that is feature complete. Torsten's work in the 286 branch has
>> almost caught up with the draft spec. Both Exo and JBoss portal has
>> preliminary (alpha/beta) jsr-286 releases. We should not be that far
>> behind.
When, assuming this is a goal, is a good time for 286 to get promoted to
trunk? And if so, what is the best way to go about doing this?
Backporting 286 patches from the branch back to trunk?
> There's no reason why we can't do both. OS is about scratching your own
> itch. If someone wants to work on 1.2.x, then go for it. If you want
> to focus on 2.x, then by all means - do it! Shoot, if someone wanted to
> dig up 1.0.x they are welcome to do that as well.
Sure, but it helps to have the community in agreement if not to marshal
resources at least to have their good will. In some cases community
coordination is essential to success. The reality is having the itch
isn't always enough.
>
> David
>
>
>> /Craig
>>
>>
>>
>> *Elliot Metsger <em...@jhu.edu>*
>>
>> 07/16/2007 10:00 AM
>> Please respond to
>> pluto-dev@portals.apache.org
>>
>>
>>
>> To
>> pluto-dev@portals.apache.org
>> cc
>>
>> Subject
>> Re: [VOTE] Pluto 1.1.4 Release
>>
>>
>>
>>
>>
>>
>>
>>
>> Looks like the changes snuck in between the 1.1.2 and 1.1.3 release with
>> PLUTO-350 (r523130) - the relative URL provider. I'm thinking we could
>> probably take it out, but I haven't taken a thorough look.
>>
>> Of course, since the change is out there with 1.1.3, 1.1.3 users who
>> move to 1.1.5 will be broken.
>>
>> We could re-release this 1.1.4 candidate as a 1.2.0, and put a note on
>> the website noting the 1.1.3 incompatibility. Or just release 1.1.5 and
>> retract 1.1.3?
>>
>> Elliot
>>
>> David H. DeWolf wrote:
>> > -1
>> >
>> > 1.1.3 and 1.1.4 should be backwards compatible (binary and runtime
>> > compat). This looks to me like we introduced an incompatibility.
>> In the
>> > meantime, is there a workaround we can use in order to get 1.1.5
>> > released without this incompatibility?
>> >
>> > This type of change can be added to 1.2.x BUT should be specifically
>> > mentioned in an "upgrade" guide.
>> >
>> > David
>> >
>> > Charles Severance wrote:
>> >> Elliot,
>> >>
>> >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the
>> following:
>> >>
>> >>
>> /Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128:
>>
>> >>
>> org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider
>>
>> >> is not abstract and does not override abstract method
>> >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
>> >> class SakaiPortletURLProvider implements PortletURLProvider
>> >>
>> >> Has an API changed? I am happy to update Sakai, adding methods or
>> >> whatever - let me know if this was an intentional change.
>> >>
>> >> /Chuck
>> >>
>> >>
>>
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by Elliot Metsger <em...@jhu.edu>.
Craig
sorry i'm super sporadic today, and i don't mean to start all these
threads all having to do with the same issue. This is probaby the best
thread to discuss this stuff.
What about just beginning to promote 286 code to the trunk, and doing
away with the 286 branch? We'd do it by applying diffs of the 286
branch to trunk.
Since we've never done a 1.2 release, we can re-branch for that later if
we want. Since svn is so cool :)
Elliot
CDoremus@hannaford.com wrote:
> David,
>
> Thanks for reminding me about this. Yes, we can all go off in any number
> of directions if we want.
>
> I intend to start focussing my efforts on the 286-COMPATILIBITY branch.
> merging the code with the current trunk and pushing out a Pluto 2.0 alpha
> or beta release. I hope that others in the Pluto community will join me in
> that effort.
> /Craig
>
>
>
>
>
> "David H. DeWolf" <dd...@apache.org>
> 07/16/2007 12:44 PM
> Please respond to
> pluto-dev@portals.apache.org
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
>
>
>
>
>
>
>
>
> CDoremus@hannaford.com wrote:
>
>> I am very much against moving toward a 1.2.0 release. We should not get
>> mired in a 1.2.x release cycle of a JSR-168 impl. We need to start
>> moving toward jsr-286. The jsr-286 EG will be releasing a public draft
>> soon that is feature complete. Torsten's work in the 286 branch has
>> almost caught up with the draft spec. Both Exo and JBoss portal has
>> preliminary (alpha/beta) jsr-286 releases. We should not be that far
>> behind.
>
> There's no reason why we can't do both. OS is about scratching your own
> itch. If someone wants to work on 1.2.x, then go for it. If you want
> to focus on 2.x, then by all means - do it! Shoot, if someone wanted to
> dig up 1.0.x they are welcome to do that as well.
>
> David
>
>
>> /Craig
>>
>>
>>
>> *Elliot Metsger <em...@jhu.edu>*
>>
>> 07/16/2007 10:00 AM
>> Please respond to
>> pluto-dev@portals.apache.org
>>
>>
>>
>> To
>> pluto-dev@portals.apache.org
>> cc
>>
>> Subject
>> Re: [VOTE] Pluto 1.1.4 Release
>>
>>
>>
>>
>>
>>
>>
>>
>> Looks like the changes snuck in between the 1.1.2 and 1.1.3 release with
>> PLUTO-350 (r523130) - the relative URL provider. I'm thinking we could
>> probably take it out, but I haven't taken a thorough look.
>>
>> Of course, since the change is out there with 1.1.3, 1.1.3 users who
>> move to 1.1.5 will be broken.
>>
>> We could re-release this 1.1.4 candidate as a 1.2.0, and put a note on
>> the website noting the 1.1.3 incompatibility. Or just release 1.1.5 and
>> retract 1.1.3?
>>
>> Elliot
>>
>> David H. DeWolf wrote:
>> > -1
>> >
>> > 1.1.3 and 1.1.4 should be backwards compatible (binary and runtime
>> > compat). This looks to me like we introduced an incompatibility. In
> the
>> > meantime, is there a workaround we can use in order to get 1.1.5
>> > released without this incompatibility?
>> >
>> > This type of change can be added to 1.2.x BUT should be specifically
>> > mentioned in an "upgrade" guide.
>> >
>> > David
>> >
>> > Charles Severance wrote:
>> >> Elliot,
>> >>
>> >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the
> following:
>> >>
>> >>
>>
> /Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128:
>
>> >>
>>
> org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider
>
>> >> is not abstract and does not override abstract method
>> >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
>> >> class SakaiPortletURLProvider implements PortletURLProvider
>> >>
>> >> Has an API changed? I am happy to update Sakai, adding methods or
>> >> whatever - let me know if this was an intentional change.
>> >>
>> >> /Chuck
>> >>
>> >>
>>
>
>
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by Benjamin Gould <be...@netsos.com>.
Craig,
I've been anticipating working with an alpha or beta of a branch that
is working towards 286 compatibility, but I am just wondering about the
status of the current 286-COMPATIBILITY branch. I have been holding off
on developing my portal until there is at least a somewhat stable
version. If this is the case with the current 286 branch, I'll start
working with it and report or help fix any issues that I come across.
Do you think that the current branch is at least good enough to get
started with, or should I wait until some of the recent updates from
trunk get applied?
Thanks,
Ben
On Mon, 2007-07-16 at 14:13 -0400, CDoremus@hannaford.com wrote:
>
> David,
>
> Thanks for reminding me about this. Yes, we can all go off in any
> number of directions if we want.
>
> I intend to start focussing my efforts on the 286-COMPATILIBITY
> branch. merging the code with the current trunk and pushing out a
> Pluto 2.0 alpha or beta release. I hope that others in the Pluto
> community will join me in that effort.
> /Craig
>
>
>
>
> "David H. DeWolf"
> <dd...@apache.org>
>
> 07/16/2007 12:44 PM
> Please respond to
> pluto-dev@portals.apache.org
>
>
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> Next few releases
> (was Re: [VOTE]
> Pluto 1.1.4
> Release)
>
>
>
>
>
>
>
>
>
>
> CDoremus@hannaford.com wrote:
>
> >
> > I am very much against moving toward a 1.2.0 release. We should not
> get
> > mired in a 1.2.x release cycle of a JSR-168 impl. We need to start
> > moving toward jsr-286. The jsr-286 EG will be releasing a public
> draft
> > soon that is feature complete. Torsten's work in the 286 branch has
> > almost caught up with the draft spec. Both Exo and JBoss portal has
> > preliminary (alpha/beta) jsr-286 releases. We should not be that
> far
> > behind.
>
> There's no reason why we can't do both. OS is about scratching your
> own
> itch. If someone wants to work on 1.2.x, then go for it. If you
> want
> to focus on 2.x, then by all means - do it! Shoot, if someone wanted
> to
> dig up 1.0.x they are welcome to do that as well.
>
> David
>
>
> > /Craig
> >
> >
> >
> > *Elliot Metsger <em...@jhu.edu>*
> >
> > 07/16/2007 10:00 AM
> > Please respond to
> > pluto-dev@portals.apache.org
> >
> >
> >
> > To
> > pluto-dev@portals.apache.org
> > cc
> >
> > Subject
> > Re: [VOTE] Pluto 1.1.4 Release
> >
> >
> >
> >
> >
> >
> >
> >
> > Looks like the changes snuck in between the 1.1.2 and 1.1.3 release
> with
> > PLUTO-350 (r523130) - the relative URL provider. I'm thinking we
> could
> > probably take it out, but I haven't taken a thorough look.
> >
> > Of course, since the change is out there with 1.1.3, 1.1.3 users who
> > move to 1.1.5 will be broken.
> >
> > We could re-release this 1.1.4 candidate as a 1.2.0, and put a note
> on
> > the website noting the 1.1.3 incompatibility. Or just release 1.1.5
> and
> > retract 1.1.3?
> >
> > Elliot
> >
> > David H. DeWolf wrote:
> > > -1
> > >
> > > 1.1.3 and 1.1.4 should be backwards compatible (binary and
> runtime
> > > compat). This looks to me like we introduced an incompatibility.
> In the
> > > meantime, is there a workaround we can use in order to get 1.1.5
> > > released without this incompatibility?
> > >
> > > This type of change can be added to 1.2.x BUT should be
> specifically
> > > mentioned in an "upgrade" guide.
> > >
> > > David
> > >
> > > Charles Severance wrote:
> > >> Elliot,
> > >>
> > >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the
> following:
> > >>
> > >>
> > /Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128:
> >
> > >>
> >
> org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider
> >
> > >> is not abstract and does not override abstract method
> > >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
> > >> class SakaiPortletURLProvider implements
> PortletURLProvider
> > >>
> > >> Has an API changed? I am happy to update Sakai, adding methods
> or
> > >> whatever - let me know if this was an intentional change.
> > >>
> > >> /Chuck
> > >>
> > >>
> >
>
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by Benjamin Gould <be...@netsos.com>.
Craig,
I'm very willing to start working with an alpha or beta of a branch that
is working towards 286 compatibility, but I am just wondering about the
status of the current 286-COMPATIBILITY branch. I have been holding off
on developing my portal until there is at least a somewhat stable
version. If this is the case with the current 286 branch, I'll start
working with it and report or help fix any issues that I come across.
Do you think that the current branch is at least good enough to get
started with, or should I wait until some of the recent updates from
trunk get applied?
Thanks,
Ben
On Mon, 2007-07-16 at 14:13 -0400, CDoremus@hannaford.com wrote:
>
> David,
>
> Thanks for reminding me about this. Yes, we can all go off in any
> number of directions if we want.
>
> I intend to start focussing my efforts on the 286-COMPATILIBITY
> branch. merging the code with the current trunk and pushing out a
> Pluto 2.0 alpha or beta release. I hope that others in the Pluto
> community will join me in that effort.
> /Craig
>
>
>
>
> "David H. DeWolf"
> <dd...@apache.org>
>
> 07/16/2007 12:44 PM
> Please respond to
> pluto-dev@portals.apache.org
>
>
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> Next few releases
> (was Re: [VOTE]
> Pluto 1.1.4
> Release)
>
>
>
>
>
>
>
>
>
>
> CDoremus@hannaford.com wrote:
>
> >
> > I am very much against moving toward a 1.2.0 release. We should not
> get
> > mired in a 1.2.x release cycle of a JSR-168 impl. We need to start
> > moving toward jsr-286. The jsr-286 EG will be releasing a public
> draft
> > soon that is feature complete. Torsten's work in the 286 branch has
> > almost caught up with the draft spec. Both Exo and JBoss portal has
> > preliminary (alpha/beta) jsr-286 releases. We should not be that
> far
> > behind.
>
> There's no reason why we can't do both. OS is about scratching your
> own
> itch. If someone wants to work on 1.2.x, then go for it. If you
> want
> to focus on 2.x, then by all means - do it! Shoot, if someone wanted
> to
> dig up 1.0.x they are welcome to do that as well.
>
> David
>
>
> > /Craig
> >
> >
> >
> > *Elliot Metsger <em...@jhu.edu>*
> >
> > 07/16/2007 10:00 AM
> > Please respond to
> > pluto-dev@portals.apache.org
> >
> >
> >
> > To
> > pluto-dev@portals.apache.org
> > cc
> >
> > Subject
> > Re: [VOTE] Pluto 1.1.4 Release
> >
> >
> >
> >
> >
> >
> >
> >
> > Looks like the changes snuck in between the 1.1.2 and 1.1.3 release
> with
> > PLUTO-350 (r523130) - the relative URL provider. I'm thinking we
> could
> > probably take it out, but I haven't taken a thorough look.
> >
> > Of course, since the change is out there with 1.1.3, 1.1.3 users who
> > move to 1.1.5 will be broken.
> >
> > We could re-release this 1.1.4 candidate as a 1.2.0, and put a note
> on
> > the website noting the 1.1.3 incompatibility. Or just release 1.1.5
> and
> > retract 1.1.3?
> >
> > Elliot
> >
> > David H. DeWolf wrote:
> > > -1
> > >
> > > 1.1.3 and 1.1.4 should be backwards compatible (binary and
> runtime
> > > compat). This looks to me like we introduced an incompatibility.
> In the
> > > meantime, is there a workaround we can use in order to get 1.1.5
> > > released without this incompatibility?
> > >
> > > This type of change can be added to 1.2.x BUT should be
> specifically
> > > mentioned in an "upgrade" guide.
> > >
> > > David
> > >
> > > Charles Severance wrote:
> > >> Elliot,
> > >>
> > >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the
> following:
> > >>
> > >>
> > /Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128:
> >
> > >>
> >
> org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider
> >
> > >> is not abstract and does not override abstract method
> > >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
> > >> class SakaiPortletURLProvider implements
> PortletURLProvider
> > >>
> > >> Has an API changed? I am happy to update Sakai, adding methods
> or
> > >> whatever - let me know if this was an intentional change.
> > >>
> > >> /Chuck
> > >>
> > >>
> >
>
Re: Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
Posted by CD...@hannaford.com.
David,
Thanks for reminding me about this. Yes, we can all go off in any number
of directions if we want.
I intend to start focussing my efforts on the 286-COMPATILIBITY branch.
merging the code with the current trunk and pushing out a Pluto 2.0 alpha
or beta release. I hope that others in the Pluto community will join me in
that effort.
/Craig
"David H. DeWolf" <dd...@apache.org>
07/16/2007 12:44 PM
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev@portals.apache.org
cc
Subject
Next few releases (was Re: [VOTE] Pluto 1.1.4 Release)
CDoremus@hannaford.com wrote:
>
> I am very much against moving toward a 1.2.0 release. We should not get
> mired in a 1.2.x release cycle of a JSR-168 impl. We need to start
> moving toward jsr-286. The jsr-286 EG will be releasing a public draft
> soon that is feature complete. Torsten's work in the 286 branch has
> almost caught up with the draft spec. Both Exo and JBoss portal has
> preliminary (alpha/beta) jsr-286 releases. We should not be that far
> behind.
There's no reason why we can't do both. OS is about scratching your own
itch. If someone wants to work on 1.2.x, then go for it. If you want
to focus on 2.x, then by all means - do it! Shoot, if someone wanted to
dig up 1.0.x they are welcome to do that as well.
David
> /Craig
>
>
>
> *Elliot Metsger <em...@jhu.edu>*
>
> 07/16/2007 10:00 AM
> Please respond to
> pluto-dev@portals.apache.org
>
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> Re: [VOTE] Pluto 1.1.4 Release
>
>
>
>
>
>
>
>
> Looks like the changes snuck in between the 1.1.2 and 1.1.3 release with
> PLUTO-350 (r523130) - the relative URL provider. I'm thinking we could
> probably take it out, but I haven't taken a thorough look.
>
> Of course, since the change is out there with 1.1.3, 1.1.3 users who
> move to 1.1.5 will be broken.
>
> We could re-release this 1.1.4 candidate as a 1.2.0, and put a note on
> the website noting the 1.1.3 incompatibility. Or just release 1.1.5 and
> retract 1.1.3?
>
> Elliot
>
> David H. DeWolf wrote:
> > -1
> >
> > 1.1.3 and 1.1.4 should be backwards compatible (binary and runtime
> > compat). This looks to me like we introduced an incompatibility. In
the
> > meantime, is there a workaround we can use in order to get 1.1.5
> > released without this incompatibility?
> >
> > This type of change can be added to 1.2.x BUT should be specifically
> > mentioned in an "upgrade" guide.
> >
> > David
> >
> > Charles Severance wrote:
> >> Elliot,
> >>
> >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the
following:
> >>
> >>
>
/Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128:
>
> >>
>
org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider
>
> >> is not abstract and does not override abstract method
> >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
> >> class SakaiPortletURLProvider implements PortletURLProvider
> >>
> >> Has an API changed? I am happy to update Sakai, adding methods or
> >> whatever - let me know if this was an intentional change.
> >>
> >> /Chuck
> >>
> >>
>