Hi,
On 27 Jun 2016, at 16:09, Ecaterina Moraru (Valica) <valicac@gmail.com> wrote:
Do we have a strategy for retired projects?
They have been marked as [Retired] in JIRA, but this doesn't prevent users from creating issues or add new code there.
Hmm I was going to say that whoever did this forgot to set the proper workflow in jira for retired projects but I’ve checked and I couldn’t see one (there used to be one but maybe we’ve removed it to allow people to raise jira for old versions?) :) So indeed we need to decide if we want to define a retired workflow that doesn’t allow creating new jira. It seems like a good idea to me. Anyone remember we may not want to do this?
Should we have deleted the contrib sources?
I’d do: * remove the sources from master * mention the deprecation in the README (and the new place if there’s one) * keep the branches/tags
Should we at least change permissions and restrict creation of issues and code commits? Do we plan to maintain in parallel the 2 repos?
No, unless some xwiki-contrib committer wants to do the maintenance. Thanks -Vincent
Thanks, Caty
On Thu, Dec 4, 2014 at 2:29 PM, Victor Rachieru <victor.rachieru@xwiki.com> wrote:
The new module can be a new version of the one on xwiki-contrib and not break the extensions that have a dependency to the old module.
The script service basically remains intact. The methods contained by that service maintain the same signatures. Nothing has changed from this point of view. So previous versions of the ratings module (the ones from contrib) can use the service just as before without it breaking things.
The issue that arises from changing the package name is that any code that uses classes from that package explicitly will be broken.
Example: ----- Say you have a java or groovy script in which you want to use a class from the ratings api package or typed variables. That code will be broken due to the fact that packages don't match anymore.
org.xwiki.contrib.ratings.Rating myRating = new org.xwiki.contrib.ratings.Rating(); or org.xwiki.contrib.ratings.RatingAPI myRating = services.ratings.getRating(doc, author);
on the other hand
services.ratings.getRating(doc, author).getVote(); should be ok
The question is: ----- Is there somebody who used classes from the api package in their code or the use of this module has been limited to calling the service from velocity and just setting/getting votes?
Thanks, Victor
On Wed, Dec 3, 2014 at 5:30 PM, Thomas Mortagne <thomas.mortagne@xwiki.com
wrote:
On Wed, Dec 3, 2014 at 4:11 PM, Victor Rachieru <victor.rachieru@xwiki.com> wrote:
Hei devs,
I intend to integrate the ratings application which is now on xwiki-contrib into the xwiki-platform.
This in mainly due to 3 points: ----- 1/ give the ability to use ratings in a wiki 2/ using it to provide ratings for the Extension Repository Application (XWIKI-7780) 3/ display ratings within Extension Manager (XWIKI-11509)
The first point can be accomplished by using the ratings app as is but the other two imply that the ratings app should be a module that is maintained by XWiki. It makes sense that if the Extension Repository App and Extension Manager which are maintained by XWiki depend on the Ratings App, that this itself is maintained by XWiki as well.
The steps needed for this is as follows: ----- 1/ create a new module in the xwiki-platform core for the ratings - xwiki-platform-core -- xwiki-platform-ratings --- xwiki-platform-ratings-api --- xwiki-platform-ratings-ui 2/ change the artifact id from "application-ratings" to "xwiki-platform-ratings" 3/ change the package from "org.xwiki.contrib.ratings" to "org.xwiki.platform.ratings"
Implications ----- 1/ clone of the existing code is now in xwiki-platform under a different artifact id (having duplicate code, this takes us to #2) 2/ the code from xwiki-contrib would probably have to be deemed as "retired" 3/ the applications with a dependency to the xwiki-contrib ratings would have to be upgraded to depend on the module from xwiki-platform 4/ the script service would remain unchanged (changing the artifact id and package name does not affect the service) 5/ if by any chance someone has code that uses the classes from the ratings app on contrib, by upgrading, that code will cease to function
Please state you position on this matter.
Links ----- http://extensions.xwiki.org/xwiki/bin/view/Extension/Ratings+API
http://extensions.xwiki.org/xwiki/bin/view/Extension/Ratings+Application
https://github.com/xwiki-contrib/application-ratings
Thank you, Victor _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Either the the new module is a new version and it should keep retro-compatibility to not instantly break all extensions using the old app when you upgrade XWiki (but given the fact that we are not going to keep org.xwiki.contrib.ratings package I doubt this is an option) or we make sure the new module and the old module can run at the same time in the same instance which means no conflicts (different script service ids, different pages names when they are completely different from old ones, etc).
-- Thomas Mortagne