versioning scheme and breaking changes
- Langage dominant
- Java
- Étoiles
- 130
- Forks
- 21
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
Hi,
Would be great if you could change the current versioning scheme to respect the most used [semantic versionning](versioning ):
> Summary
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards compatible manner, and
> PATCH version when you make backwards compatible bug fixes.
It's a pain every time we update our dependencies, we have to remember that assertj has breaking changes even though only minor version were updated.
By the way, we're stuck on version 3.17 because of this change:
> Breaking change: disable bare name getter by default, to get the previous behaviour back, call Assertions.setExtractBareNamePropertyMethods(true);
What's the simplest way to get the previous behaviour? Adding this line in every test?
Regards
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par examiner le processus actuel de versioning et de release du projet, puis étudiez la breaking change décrite pour la version 3.17. C'est terminé lorsque le projet respecte le Semantic Versioning pour les changements incompatibles, compatibles et les corrections de bugs, avec un chemin de migration clair pour rétablir le comportement précédent.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- java
- Domaine
- release
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 30/100