[Building Sakai] [Management] Deprecation summary page

[Clay Fenlason]

OK, good to know, but to be clear, I think it's the clear preference
for 2.7 for Profile classic to remain as an option. We have done
nothing in prior releases to signal its departure, and yanking it out
of 2.7 at this stage has the potential to be disruptive. It would be
surprising if someone missed it, but we should operate on that basis.

Post-2.7, we should look at moving it from trunk to contrib. Perhaps
very soon post-2.7.

Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the
interface)? I think we should label both simply 'Profile,' and leave
it to institutions to configure for the classic version in the
unlikely event they opt to.

~Clay

On Wed, Mar 24, 2010 at 6:08 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
>
> The actual Profile classic tool can be removed (ie the webapp).  As Aaron
> pointed out, Roster depends on the Profile classic API, so at the moment,
> that needs to stay.
> Profile2 provides an implementation of the ProfileManager that gets it's
> data from Profile2, so the Roster can use this instead. This is currently in
> place and can be switched around via an entry in sakai.properties:
>
> # Set this to tell the ProfileManager to get it's data from Profile2.
> # If left unset, any tools that use the ProfileManager from the original
> profile tool (ie Roster)
> # will continue to use the data from
> org.sakaiproject.api.app.profile.LegacyProfileManager.
> # So you must set this to enable the integrations.
> # If you are using a version of Sakai prior to 2.7, you need to apply the
> patch attached to
> # http://jira.sakaiproject.org/browse/SAK-17573 in order for this property
> to have any effect
> profile.manager.integration.bean=org.sakaiproject.profile2.legacy.ProfileManager
>
> However, the Roster is still looking at the Profile/ProfileImpl models from
> the Profile classic API for it's information. Some work needs to be done
> with the Roster to abstract this part out to somewhere else.
> For now, we should be able to remove the profile classic tool and leave the
> API.
> cheers,
> Steve
>
> On 25/03/2010, at 1:34 AM, Clay Fenlason wrote:
>
> OK, got it. Thanks.
>
> ~Clay
>
> On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <david.horwitz at uct.ac.za>
> wrote:
>
> Hi
>
> a) Profile classic is still in 2.7.x?
>
> yes
>
> b) if you unstealth it, it should continue to function as before?
>
>
> Because of the way its used "stealthed" doesn't realy apply to profile
>
> classic. You could leave it in your my workspaces templates and it would
>
> continue to work as before...
>
>
> D
>
>
> There isn't really a way to mark a tool as deprecated.
>
> In the policy draft I've put forward, tool deprecation entails:
>
> 1) Stealthing the tool
>
> 2) Listing it as deprecated in the release notes, and announcing the
>
> same on-list
>
> 3) Removing it to contrib in the next feature release, assuming there
>
> aren't extenuating circumstances that would argue for keeping it
>
> around longer (eg. if a migration path still needs to be worked out)
>
> ~Clay
>
>
> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
>
> <clay.fenlason at et.gatech.edu> wrote:
>
> Some outstanding questions I'd like to get more comment on:
>
> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>
> about this?
>
> 2) I've tried to represent the JCR and Static Cover issues as well as
>
> I understand them [1], but would welcome clarity from my betters. At
>
> the time of this writing, we're still ping-ponging the issue of
>
> whether to actually flag static covers as deprecated, but seem to have
>
> come to agreement on the rest (retain them, but remove their use from
>
> core code).
>
> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>
> not, for example, explain if anything will be done for 2.7. I'm
>
> inclined to think that this would be appropriate for kernel 1.2, but
>
> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>
> 3rd-party utils?
>
> 4) I confess to a bit of uncertainty about the state of the two
>
> Profile tools. I was under the impression in December [2] that the two
>
> profiles couldn't work together, but it looks like Steve managed to
>
> complete the work that allowed them to do so [3]. And yet something
>
> about Aaron's description of removing remaining dependencies to
>
> Profile 1 makes me wonder if in fact they can still be swapped with
>
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
>
> the proposal to simply say that Profile classic should be stealthed
>
> and marked as deprecated.
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
>
> [2]
> http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>
> [3]
> http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>
> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>
> <clay.fenlason at et.gatech.edu> wrote:
>
> I'd promised I was going to work this up this past weekend, but I've
>
> been sick the last few days, and it's been delayed. Still not quite
>
> finished, but I'm feeling poorly again and need to rest a bit, so I
>
> won't delay circulating the link [1]. The latest on JCR and Static
>
> covers still isn't there.
>
> Comments and other edits of course welcome.
>
> HTH
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
>
>
> _______________________________________________
>
> sakai-dev mailing list
>
> sakai-dev at collab.sakaiproject.org
>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
>
>
>
> --
>
> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>
>
> _______________________________________________
>
> sakai-dev mailing list
>
> sakai-dev at collab.sakaiproject.org
>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
>
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
>