Thanks for explainations ! :) Well, I believe my target anyway will be 4.x (and only 4.x), compatibility for 3.x is mainly for my own use-case of replacing the old app in production with the new component. Once it's done (and my own wiki migrated to 4.x) I don't think I will bother with 3.x compatibility anymore ...
So of course if this timeframe is really short I might not even bother with a 3.x at all, but it all depends on my ability to releasing a real 1.0 soon ;-) ... (I feel I'm a bit far from that to be honest) Thanks, Jeremie 2012/10/8 Vincent Massol <[email protected]>: > > On Oct 8, 2012, at 1:12 PM, Jeremie BOUSQUET <[email protected]> > wrote: > >> About branch for 3.5.1, I wonder if there is a way to properly manage >> that with extensions manager ? >> Is it possible to provide a specific extension artifact for users >> running xwiki 3.5.1 and another one for 4.x ? > > You can have as many versions as you want of your module. > > The EM can install any version. By default it'll pick the latest version > compatible with your install but you can ask it to use any specific version. > > What you need to figure out (if you need 3.x compatibility) is how to name > the version. > > You basically have 2 solutions: > > Solution 1: You use the xwiki version in the name of your module > ======== > Example: > * xwiki-contrib-mailarchive-ui-3x-0.2 based on XE 3x > * xwiki-contrib-mailarchive-ui-4x-0.2 based on XE 4x > > And when you need to release a new version for XE 3.x you use for example: > * xwiki-contrib-mailarchive-ui-3x-0.3 based on XE 3x > > Or instead of 3x and 4x you use the exact version of XE it requires: > * xwiki-contrib-mailarchive-ui-3.5.1-0.2 based on XE 3.5.1 > * xwiki-contrib-mailarchive-ui-4.2-0.2 based on XE 4.2 > > (note to self: need to check with Thomas what version the EM think is the > most recent in this case - I don't know our algorithm - I guess it's > alphetical so 4.2-0.2 will be considered more recent than 3.5.1-0.3). > > Solution 2: You just specify in the release notes what's the minimal version > required for a given version > ======== > Example: > * xwiki-contrib-mailarchive-ui-0.2 - Works with XE 3.x > * xwiki-contrib-mailarchive-ui-0.3 - Works with XE 4.x > > And when you need to release a new version for XE 3.x you use for example: > xwiki-contrib-mailarchive-ui-0.2.1 > > It's not fully correct since it may not be a bugfix release so this second > solution works best when you follow the XE releases and only issue bugfix > releases for past XE versions. > > The most correct solution is Solution 1 of course. > > Hope it helps, > -Vincent > > PS: It's always a pain to maintain several branches, so you really need to > decide if you want to do that or just maintain one branch… ;) > >> Or is it just too painful and useless, at once, to not just provide >> the extension for last xwiki version ? >> >> 2012/10/7 Jeremie BOUSQUET <[email protected]>: >>> Hi again, >>> >>> - I pushed last updated code to git, so that version should be better >>> ... But I'm still having issues building it, so you should add >>> "-Dmaven.test.failure.ignore=true" to maven cli. It's a problem I >>> still couldn't solve: the junits for MailUtils component (in -api) >>> fail because of xwiki not finding roles for this component, while when >>> the app is deployed to a running xwiki, MailUtils component is >>> instanciated without any issue. >>> Time for an additional question : there are some specific things to do >>> to unit test a component that depends on old core, but are there any >>> for a component that depends on a component that depends on old core ? >>> - About moving to more recent xwiki version I agree, I'll create a >>> branch for 3.5.1. Will also be a motivation to finish migrating my >>> wiki to recent version :) >>> - I added MailArchiveCode.UIExtension for application panel, doesn't >>> it work ? Did not test in a 4.x myself so I'm not sure. >>> - added dependency on Tabs Macro from Mail Archive App extension, but >>> it's not listed in the page... I must have done something wrong. >>> - added dependency on -api from -ui >>> >>> Br, >>> Jeremie >>> >>> >>> 2012/10/7 Jeremie BOUSQUET <[email protected]>: >>>> Answers below, >>>> >>>> >>>> 2012/10/7 Vincent Massol <[email protected]>: >>>>> Some more feedback: >>>>> >>>>> * You should put all your technical code in the MailArchiveCode space. I >>>>> see you're putting pages in existing spaces which is not that good: >>>>> Scheduler, Extension, XApp. >>>> For Scheduler and xApp I agree, though it's the default behaviour of >>>> scheduler and application manager apps to put their descriptors in >>>> their space. >>>> For Extension it was of our decision to put documentation in Extension >>>> space on xwiki.org. I wanted to have the pages in the same relative >>>> location but anyway as I can't import those pages in xwiki.org it's >>>> useless, so I'll set them back in MailArchive space (they are not >>>> technical pages but documentation pages). >>>> >>>>> * You should mark all the technical pages as hidden docs. >>>> I don't think it existed in 3.5.1, that's why I didn't set them ;-) >>>> >>>>> * You should have a package.xml file since it's generated automatically :) >>>> I understand that I "shouldn't have" a package.xml file, am I right ? >>>> >>>>> * I see a java-libpst jar in some lib/ dir. This lib should be in maven >>>>> if it's required.* >>>> It's supposed to be used by experimental feature in specific branch, >>>> so I should remove it completely from master. >>>> >>>>> * MailArchive UI module is missing dependencies; it should depend on >>>>> xwiki-contrib-mailarchive-api for ex at least >>>> I'll fix that. >>>> >>>> I really appreciate your feedbacks ! >>>> For git I'll send a mail when fixed, because I don't exactly remember >>>> how far I went, I'll have to test that before committing. >>>> Thanks, >>>> Jeremie >>>> >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> On Oct 7, 2012, at 2:34 PM, Vincent Massol <[email protected]> wrote: >>>>> >>>>>> Hi Jeremie, >>>>>> >>>>>> I've tried using version 0.1 this week end and I've found that it >>>>>> doesn't work and is missing things. For example, it requires the tab >>>>>> macro which isn't specified as a dependency. And some pages have >>>>>> velocity macro failures. >>>>>> >>>>>> I've then tried to build the mailarchive app from git in the hope that >>>>>> some more recent commits fixed the issues but I couldn't built it. The >>>>>> build fails with: >>>>>> >>>>>> "Results : >>>>>> >>>>>> Failed tests: >>>>>> decodeMailContentForHtmlAndNoBodyAndCut(org.xwiki.contrib.mailarchive.internal.MailUtilsTest): >>>>>> To be implemented >>>>>> >>>>>> Tests in error: >>>>>> extractTypesWithLimitValues(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): >>>>>> Failed to lookup component >>>>>> [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role >>>>>> [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] >>>>>> extractTypesForNominalCases_OtherType(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): >>>>>> Failed to lookup component >>>>>> [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role >>>>>> [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] >>>>>> extractTypesForMultiplePatternsAndTypes(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): >>>>>> Failed to lookup component >>>>>> [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role >>>>>> [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] >>>>>> >>>>>> Tests run: 10, Failures: 1, Errors: 3, Skipped: 0 >>>>>> " >>>>>> >>>>>> I've also noticed that on master the core dep is 3.5.1 which is pretty >>>>>> old. I'd like to update this to 4.3-SNAPSHOT and when you perform a >>>>>> release you resolve the snapshot to whatever version is the latest >>>>>> released (ATM that would be 4.2 and later on that would be >>>>>> 4.3-milestone-1 for ex). >>>>>> >>>>>> If you still need to depend on 3.5.1, it should be done on a branch of >>>>>> the mail archive app IMO. >>>>>> >>>>>> It would be nice for ex to be able to use the Application panel >>>>>> extension point. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> I'm now going to try building with -DskipTests and pray it's going to >>>>>> run ;-) >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>> PS: I'm still very eager to see it in action! >>>>> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
