Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reorders 'saving' and 'creating' triggers as per docs. #1142
The docs suggest the ordering of triggers on the Model are:
Currently Saving is triggered after Creating/Updating. I am using Saving to hook in a validation of the model, and I want to validate it before saving (for example validate that a password and password confirmation are the same, but then delete the password confirmation as I don't want to store it in the database).
Jan 9, 2018
1 check passed
@ricardograca I don't understand why this got released in a minor. This is a breaking change. In my opinion this change belongs into a major release
Edit: Just to be clear. I agree that this was (maybe) a wrong implementation from the beginning, but if you have a big application which relied on this code since it was added, it's breaking your code. I am saying "maybe", because i am not sure that this order makes really sense.
I assume it will break every code, which makes use of
I think this commit needs a revert + a re-release
Well, I'm following semver here that states that:
Here X is 0 so this doesn't apply.
I don't think this should be reverted, because it would just be postponing the problem, and version 0.x is precisely to test things and to potentially break stuff. My idea is to try to get to a point where a major 1.0.0 version will be stable for as long as possible, so some breakage will occur before that.
Do you have any real world examples of this breaking any code or is it more a theoretical problem?
Bookshelf is not in the state of initial development. Bookshelf missed the point to release a 1.0.0 to be able to then follow the semver restrictions (breaking changes in major versions). We are using bookshelf for > 3-4 years.
If you are using a custom id value for example. You relied on the fact that
Edit: If you are validating your model against a schema. You relied on the fact that
I don't really agree. You can decide (the user who uses bookshelf) if you want to upgrade to the next major and schedule time to correct breaking changes.
That's debatable. There have been some breaking changes over the years, and we never released a 1.0.0. Time is not what determines if something is stable or in development.
Your example makes sense, but is it a real example or a hypothetical one? Because unless someone comes up and actually complaints about this change breaking actual programs and doing the necessary changes to their code base not being a viable option because it would be too daunting of a task and they really need some change that was introduced with 0.13.0 then I don't see a reason to revert this.
If someone is worried about this change breaking something they can always stay on version 0.12.1. If the problem is not being able to update code then why would you even update a dependency?
However I also don't want to purposely cause anyone harm, so if you can provide a valid reason that is not based on theoretical problems then we can always backport the other non-breaking changes to the 0.12.x branch.
Both examples i've shared are real cases. The release
I am not saying we have to revert this commit only because of Ghost, but Ghost is i think one of the biggest platform using bookshelf and i think we have to take care shipping breaking changes for a project which is in my opinion, as said in my previous comment, not in the initial development state anymore.
Also from https://semver.org/:
Ghost is using bookshelf on production for more than 3 years.
If bookshelf continues with sticking with 0.x, people have to adapt the breaking changes, otherwise they won't receive important bug fixes, which is now the case. And breaking changes like changing the order of events in an ORM, is nothing you can fix within a minute in a bigger application.
Ok, those are valid examples. The thing is that the order of events will change eventually, so what difference does it make if it's now or 3 months from now? You will have to adapt your code base anyway right? That said I don't mind postponing this change until the next release, if that is a good compromise for you, but it has to be released at some point.
Also, there are other breaking changes in this release, including your PR about running async events in sync. It probably doesn't affect as many people but it doesn't change the fact that it is a breaking change, so should it also be removed? Breaking changes will occur and I would rather not pile them up all for the future 1.0.0 release.
As for the current version names I agree that Bookshelf should have released version 1.0.0 long ago, but that hasn't happened yet, so I'm trying to work towards it. In the mean time there will be some breakage.
However I don't think your problem is the version number, since if we were already at a major version this would be the next major version and everything else would be the same and you would still be complaining about the order of events.
In the future would it help if I do some pre-releases before the final versions? Would that give you enough time to prepare for any potential changes?
BTW, I will be unable to do a new release in the next couple of hours, but if you make the necessary changes you can merge them and I'll do a release as soon as I get the chance.
Also, this will be a 0.13.1 release, which breaks semver, but I don't think anyone has built an application yet depending on the order of events of version 0.13.0.
The difference is that if we would have released a proper 1.x version (not saying this is your fault
I would suggest to keep this as is and release a 1.x asap
Good points, but I'm working for free and practically alone on this, so there's just so much I can do to support older branches and backport important fixes. However I created a 0.12 branch a while back precisely to be able to do this if needed. If someone else complains about one of the breaking changes I'll look into making a point release in the 0.12 branch.
I'm glad you got it sorted. I'll keep you posted on important breaking changes in the future.
I'm working on it!