Closed pedrobaeza closed 1 year ago
Hi All - How are we going to handle this? I vote this gets put on the afterburner until we move 8.0 incubator into 8.0.
I agree with @lasley : first we have to move 8.0-incubator into 8.0 before starting 9.0
Sweet, glad we're on the same page @JonathanNEMRY. Looks like we're getting close to the finish line on the 8.0-incubator too :smile:
What is the progress on migrating to 8.0?
As far as I know, 0%. Working on a pharmacy module on my end at the moment, but that's in 8.0.
I'm hoping to start tackling 9.0 soon, but we would definitely need to make sure that the >10 PRs currently pending are finalized before even attempting that
How close are those PRs to being ready?
I'm considering deploying Vertical-Medical, but I feel it might be best to wait if 8.0 will be finished within less than a month.
They're all ready IIRC, just need to be reviewed and merged. My team is internally targeting mid-Feb for 9.0
I'll wait until February then, thanks!
FYI now that 8.0 PR is submitted, we've planned out what we need for 9.0.
My team will take on the following modules, and should be done in the next few weeks (some are already done):
The following modules are not within the scope of our current project, so if someone else would like to coordinate on them let me know (we're open for volunteers on the above too :stuck_out_tongue_closed_eyes: ) - My team likely won't be touching them for a while:
@pedrobaeza -
Would you mind updating your 9.0 conversion requirements for the new module layout above?
Additionally - In the interest of being lazy and not re-resolving all the conflicts, I propose that we recreate the 9.0 branch from 8.0 once merged, then just re-run the upgrade script. As far as I can tell, that's the only change there. Maybe other suggestions?
OK, I have already updated the issue, and please ping when your PRs are merged on 8.0 branch to forward copy to 9.0 before starting migration.
Awesome thank you!
We are adding team to speed this up!
@JayVora-SerpentCS - Awesome, let's coordinate on this then.
PRs are currently pending for about half of the ones I listed in my comment above as being completed on my end, which I believe cover all dependencies for the rest of the modules.
You looking to start anywhere in specific, or just looking to get everything to 9.0 as a whole?
As a general note, the modules with oemedical
prefix have not yet been touched as part of this massive dev push (to 8.0). Anything with medical
prefix should be fairly up to date, but is likely lacking in test coverage.
Guess, we should make v8 modules completed first.
@JayVora-SerpentCS Honestly I was just going to skip v8 on the ones that we didn't port, but that would definitely be a good start.
The modules with oemedical
prefix need a significant amount of work before they are anything close to ready for production. The ones with medical
prefix should be somewhat good, but do not fall in line with OCA standards in a lot of ways (particularly modularity & naming).
Basically everything is 0% test coverage as well. We have made an internal goal towards 90% coverage on v9.
I would say that if you're going to just flat out upgrade a module without restructuring, please only bring it to v8. We can then use v9 as a staging for truly good modules. This library has a significant amount of errors as is, and will require a lot of QA to actually upgrade.
Hi folks, and thanks for your hard work on this project! I extended the appointment module to generate invoice automaticaly when app is done, for one of my clients. Would you be interested on this? I don't want to waste your time.
Yeah, it can be an interesting module. You can make a PR for it.
@askz There is already a medical_invoice module, does this by any chance upgrade any of that logic?
(also any contribution is welcome IMO)
Of course, that's the spirit of OCA! It can follow 2 approaches:
It's convenient though to take into account if there's already an existing feature about it, because it's not allowed in OCA by default 2 modules that covers the same feature.
@lasley an invoice is an invoice IMO, invoice must stay an account_invoice and we should avoid to define a new model for this transverse concept.
@lasley yup. Actually I've taken the snippet that generate the invoice and invoking it when stage is 'done' :
@lmignon you're totally right, and I haven't done that. Just generating account.invoice when an appointment is done ;) Sorry for the spam, I'll open an issue when my code will be reviewed a little.
@lmignon That makes sense, I think I mis-posed my question. Really I was asking if the logic had been moved from the invoice module, or if it was new.
Part of the direction of my inquiry was actually due to the logic I had seen in the pre-existing library, and the fact that it did not use the account.invoice core.
@askz Any way to switch this a bit so that it's using account.invoice instead?
@lasley I edited my last comment. And this is what I did. But I'm constrained to inherit medical.appointment. Since I'm a newbie in odoo development too.
@askz Bit of history - this library has a lot of modules that were combined into super-modules of sorts. We've been working at breaking them up into their independent features, as well as isolate to what the modules are actually working with. You can really see this history by looking at the ones we haven't touched yet, like medical_invoice.
Is your existing code in your repo somewhere so I can take a look? I'd be happy to offer a bit of assistance.
@lasley okay great. Thanks for this rewind. I'll do a public release in the end of the week, I have to work on this a little. Thanks for your assistance guys!
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
Todo
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0
Modules to migrate