Release Cycle and Support

[henriquemoody]

It's very important for us to discuss about this. I know we've discussed it early (Respect/project-info#2) but I think every project must have its own release process.

MAJOR/MINOR versions

• Every 6 months
• No need of pre-releases

It's a very acceptable interval, IMO.

PATCH versions

• Release right after the bug fix

Actually, that's what happens today.

Version support

• The last 2 MINOR versions
• The last released version of the last MAJOR version

Scenario 1:

• The last released version is 2.5
• The last released version of the last MAJOR version is 1.8

We give support for 1.8, 2.5 and 2.4.

Scenario 2:

• The last released version is 2.0
• The last released version of the last MAJOR version is 1.8

We give support for 1.8 and 2.0.

[augustohp]

👍

[alganet]

(Y)

[augustohp]

How we should expose this? There is any pattern on keeping this inside a code repository? Maybe a RELEASES.md file at the root directory of the project?

[henriquemoody]

I think we can use the Wiki for that.

[alganet]

The main README.md should be enough, right? When a branch is deprecated, we put on that specific branch:

(This version is deprecated, please see <link to project home/wiki/packagist>)

[henriquemoody]

+1 for @alganet's comment, but I think the @augustohp's question was more about where we expose the process itself.

[alganet]

+1 for @alganet's comment, but I think the @augustohp's question was more about where we expose the process itself.

Got it 🐼 I'd say outside the repo then, because it is information outside any branch. +1 for Wiki!

[augustohp]

Wiki is a 👍 for me too.

[williamespindola]

👍 for release and wiki

[ICarpenter]

When do you plan to release a version with updated array support for "in" exceptions?
see here: https://github.com/Respect/Validation/blob/master/library/Exceptions/ValidationException.php#L87?

I am not comfortable using master for stability reasons so having this in a release ASAP would be awesome. Thank you!

[henriquemoody]

The last release was on Apr 24, so the next one will be Oct 24, but 2 releases (MAJOR or MINOR) a year is starting to look too much time, indeed.

If we make it shorter, like 3 releases a year (1 release every 4 months) the support for will be only 8 months, which is not that bad since we have LTS for the previous MAJOR version.

I'm in favor of making it shorter, 4 months to release.

Any thoughts?

---

@ICarpenter, if you commit your "composer.lock" file, which is a recommendation, you will keep the exact version when you installed it. But, I agree with you and I don't feel comfortable with this kind of situation either.

[ICarpenter]

Respect is a pretty mature codebase and the number of releases a year should not need to be more than two or three. I guess the issue is how many large features you plan on releasing in the future.

The "less than awesome" parts of the library that I have encountered are around the customization of errors. This might be remedied by adding features rather than changing existing behavior. For a little context, I work for a medium sized e-commerce platform that has started using Respect as a de-facto standard for validation. We would love to see more granularity in error messaging!

[henriquemoody]

I made some improvements on exception messages today, @ICarpenter (69f433d and 5a41a6b) but we cannot have more granularity control with the current design we have, probably after #354 there will be more, depending on which approach we choose.

[henriquemoody]

The wiki has been updated.