Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEW Thirdparty - Can upload a file with drag and drop #30263

Merged
merged 1 commit into from
Jul 4, 2024

Conversation

aspangaro
Copy link
Member

image

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro how are you Alexandre ?

@aspangaro
Copy link
Member Author

Fine @hregis ans you ?

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro
I live what I have to live and when I come back to reality I realize that Dolibarr's code is getting better and better... and sometimes becoming nonsense! We accept crap code that creates... crap!
But hey... one person cannot judge the impact of a change in the code... ;-)
And as long as it's like that we'll have shitty code!
(my words are with respect) ;-)

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy
not enough time between versions, not enough time when a function has changed name, sometimes no time at all, and sometimes from one version to another a radical change that breaks the functioning of our modules.. .
No time to integrate changes for Multicompany between versions! I have them in my head, I have to add them, but no time! too much work in the meantime and when the freeze version arrives it's too late! ;-)

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy

6 months for a major release is too short ! again and again...

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy

especially to provide a shaky version after 6 months...
you might as well take the time to provide a stable version!
even if it means making intermediate versions!

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy

customers or others sick of the latest version want to update their Dolibarr...
I tell them that they must at least wait for one or two releases...
a release would have to be stable!
otherwise it's a pre-release version!

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy

there are too many codes that are not thoroughly tested and it creates side effects without us understanding why, and we have to search for hours to find where it comes from! It's tiring !

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@eldy

we need more people who check and test the code before integrating it... which necessarily requires more time... which means one major version per year and not every 6 months... we are not not pizza sellers!
It’s business management!!! ;-)

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@eldy

I don't know what world you live in, but take a step back and consider those who can't handle this very short period of time...
i love you ! ;-)

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy

a dolibarr member pays contributions, apart from the reduction on the purchase of a module, he also expects stability and professionalism on the application... bring this professionalism! that's the lesser of it !

sorry @aspangaro These words are directed towards Eldy, I took advantage of this opening to vent my anger! ;-)

i love you all ;-)

@hregis
Copy link
Contributor

hregis commented Jul 3, 2024

@aspangaro @eldy

eldy too ! i love you too ;-)

@aspangaro
Copy link
Member Author

It's clear that it's a never-ending battle: we're not done playing with one version until another comes out, and we have to support it through the various modules we can edit. You also need to have tested the version in question from top to bottom to detect undesirable effects and respond to customers who want more and more.

On the one hand, it's burdensome, but on the other, it's a big part of Dolibarr's dynamism.

Code quality has made great strides with all the CI tools, and in time this will enable us to concentrate on other points.
As @eldy explained at devcamp, we're almost moving straight to v21 for this v20, given the review that's been done.

After that, moving to a more complete version every year wouldn't be bad, but it would bring other problems and in the end, it would be a bigger version to stabilize, so it would take more time and resources, and external modules wouldn't be up to date at the time of release.

The difficulty you face is that multicompany is ultra-central to the deployment of Dolibarr. Whether or not you use your module is a matter for the early stages of a project, as it has a major impact on the management of a company, which is why you need to keep up with this crazy pace. After that, if you decided to slow down by adapting multicompany every two versions to give yourself time, it wouldn't be incomprehensible and people would probably follow you. There's also the much-discussed notion of LTS, which is every 4 versions (v14 / v18 ...). We're talking about ERP, not just software that works on a single subject.

Otherwise, you should try to integrate more multicompany functions directly into the core (and I'm only talking about this module).

Another solution is to work as a team! This allows you to divide up the work.

Take care of yourself ;)

@eldy eldy merged commit 24feabc into Dolibarr:develop Jul 4, 2024
6 of 7 checks passed
@hregis
Copy link
Contributor

hregis commented Jul 4, 2024

@aspangaro @eldy

one version per year would allow more time to resolve bugs that have been hanging around for years and no longer have to tell customers in a hurry not to upgrade to a new version because it will inevitably be bugged... it's too short to take the time to add or improve the code! customers go with one version and when we tell them that they will have to move to another version because the additions will not be present, it exasperates them! So yes we can make a git branch for them... but hey! let's stop making two major releases per year!!! Where are the Release versions? alpha, beta.. but release!
a year for a version, damn it!!! not two versions per year!
I kiss your molar...

@hregis
Copy link
Contributor

hregis commented Jul 4, 2024

@aspangaro @eldy

une version par an permettrait d'avoir plus de temps pour résoudre des bugs qui trainent depuis des années et ne plus avoir à dire au clients pressés de ne pas passser sur une nouvelle version car forcément elle sera buggée... c'est trop court pour prendre le temps d'ajouter ou améliorer le code ! les clients ils partent sur une version et quand on leurs dit qu'il va falloir passer sur une autre version car les ajouts ne seront pas présent, ça les exaspèrent ! Alors ouii on peut faire une branche git pour eux... mais bon ! arrêtons de faire deux versions majeurs par an !!! Elles sont où les versions Release ? alpha, beta.. mais release !
une année pour une version, bordel !!! pas deux versions par an !
je vous kiss la molaire...

@aspangaro aspangaro deleted the 21dragdrop2 branch July 6, 2024 03:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants