Actualmente administro una biblioteca que tiene mucho uso público, y tenía una pregunta sobre el control de versiones semántico . Quiero refactorizar una parte bastante importante de la biblioteca que se implementa incorrectamente y siempre se ha implementado incorrectamente. Pero hacer esto significaría cambios en la API pública, que es una decisión importante.
El cambio que quiero hacer gira en torno a cómo se usan los iteradores. Actualmente, los usuarios tienen que hacer esto:
while ($element = $iterator->next()) {
// ...
}
Lo cual es incorrecto, al menos en la interfaz Iterator nativa de PHP . Quiero reemplazar con esto:
while ($iterator->valid()) {
$element = $iterator->current();
// ...
$iterator->next();
}
que es análogo a:
foreach ($iterator as $element) {
// ...
}
Si nos fijamos en la guía de Tom para el control de versiones semántico, él afirma claramente que cualquier cambio en la API pública (es decir, aquellos que no son compatibles con versiones anteriores), debe justificar una versión importante. Entonces, la biblioteca saltaría de 1.7.3 a 2.0.0, lo que, para mí, es un paso demasiado lejos. Solo estamos hablando de una característica que se está arreglando.
Tengo planes de lanzar eventualmente 2.0.0, pero pensé que esto fue cuando reescribió completamente la biblioteca e implementó numerosos cambios públicos de API. ¿La introducción de esta refactorización garantiza el lanzamiento de una versión principal? Realmente no puedo ver cómo funciona, me siento más cómodo lanzándolo como 1.8.0 o 1.7.4. ¿Alguien tiene algún consejo?
next()método se utiliza para recuperar el elemento actual Y mover el puntero interno hacia adelante. Cuál está mal. next()debería mover el puntero, y current()se usa para recuperar ...
next()solo eso que mueve el puntero, esto realmente no rompe la compatibilidad