Community mailing list archives
Re: OCA project: __unported__ folder considered painfulby
2015-03-11 1:27 GMT-06:00 Alexandre Fayolle <firstname.lastname@example.org>:
1. am I the only one to feel the pain of __unported__?
I don't "like it" but from there to think it is a pain there is too much space.
I like less the job to stabilize again all the repositories.
Even in our own public branches I prefer simply mark as "installable": False modules, then when some fix comes from V7 is quickly mergeable, and maximum 1 line of conflict (the __openerp__.py itself).
Since the begining I didn't like it, but we decided the __unported__ approach, IMHO I prefer stay there and mantain the status quo on big projects with several modules.
<But honestly, I think it is so much better go back and let them simply installable: false.
2. do you think it is worthwhile to have 7.0 -> 8.0 merges for OCA projects?
It depends of the complexity of the module to answer that.
case a: 100% of stock related modules can be simply deleted, the "feature" MUST be rewritten.
case b: account_* modules (not related to bank statement) must be pretty straight forward to mantain between 2 versions.
case c: modules which add full new functionalities (medical_*) can be mantained in both versions but migrated for v9.0.+
>>>> Put here more cases
Then it is not a rule black and white in my opinion and can be decided repository by repository.
Honestly technically __unported__ was a bad Idea since the begining but we have it now and I think it do not add any value make a huge effort again, it must be discussed repo by repo and the project leader take the role of judge case by case.
3. do you have ideas how to tackle the two objectives above (preferably without going through a huge reorganisation of our repositories, cf. note below)?
I think best is have them:
1.- installable false
1.- installable false
2.- Little script that read such information and index in the README.md or in a new file the modules on such repositories that need work to be migrated.
PS: I do not like even a little the idea of 1 repo 1 module, it is a huge amount of mantainance problems I use 10 / 12 repositories by project, just think in fork 100 makes me fear that such approach will be possible in some moment), because CVS it the power of auditory and sharable code, use "normal" zip stuff and so on, will stop a lot the collaboration and will bring more and more leechers (which have not intended to be leechers but it will be so difficult to simply pull and load).
Camptocamp France SAS, Alexandre Fayolle - Camptocamp