Discussion: Version Tags

[Rican7]

Using php-activerecord with composer or any other package manager is difficult, because of the lack of version tags. Many features are missing, unless using the "master" branch, which changes often.

For this library to keep iterating, it should be version tagged in more places for markings of "stability".

Without these tags, every single pull request and commit holds a LOT more weight/responsibility.

Unfortunately, only the original repo owners have the ability to create version tags... otherwise, I'd send a pull request.

For more reasoning and a quick how-to on creating Git tags (very easy), refer to this post.

[Rican7]

A few suggestions:

• v1.1 a3c4601 - A lot has changed since version 1.0rc1, and development was consistent until this commit, when it stalled for months. That stalling most likely denotes a time of stability, as fixes weren't required to be made (other than minor, expected bugs). Changelog here
• v1.1.1 d6c4b92 - This is a bug-fix release that contains mostly test fixes, but also contains the necessary changes to work with composer (packagist). Changelog here

More could come, or there could be more minor releases in between, but these are just my quick suggestions. :)

[al-the-x]

@jpfuentes2 Make this man a contributor already...! I agree with all these suggestions...

[al-the-x]

Made this issue into a "discussion" ticket... Maybe @kla can give us a similar label for these items?

[jpfuentes2]

@al-the-x I asked you the other day and you didn't respond! I absolutely agree!

@Rican7 You've already said yes on Twitter, I believe; however, would you confirm here?

[al-the-x]

Ideally, we should have a separate branch for all this "cutting edge development" we're doing -- "develop" in git-flow terminology-- and "master" should only contain stable release points. We're making such a good push towards cleaning up this place, we completely neglected the release planning discussion. Let's fix that.

[Rican7]

@jpfuentes2 @al-the-x Haha! Thanks guys! I'm already a contributor on a few things, so I'm not sure if I'll have the time to really uphold the responsibilities, but I'd love to help, so its up to you if you'd like to give me access.

And yes, @al-the-x, we should employ a better git-flow if we can. :)

[al-the-x]

I created a "develop" branch from "master", since Github lets me do that... Of course, all these PRs are against "master" still, so we won't be able to close them against the new "develop". We can always peg v1.1.1 where you've suggested and keep on keepin' on until we work through the backlog, saving potentially dangerous PRs for "develop" (@kla, another issue tag, pls? :D)...

[Rican7]

Good idea, @al-the-x

[al-the-x]

I also made a "Push to 1.2" milestone that we can use to track our potentially breaking changes until then. Post-1.2, PRs should be based on "develop", not "master", so that we can maintain relative stability in "master".

[al-the-x]

Once we get the tests passing (see #296), we should tag again as 1.1.2 to indicate a stable build (obviously without OCI support).

[al-the-x]

I tagged those commits you suggested, @Rican7 and pushed to the repo. With the closure of #298 and all passing tests (including skipped 💩), I tagged 5a95748 as v1.1.2, as well. With all the open PRs, I feel that asking ppl to rebase onto "develop" and reopen their PRs is cumbersome. Maybe we need a "Contributing" section in the README file to point ppl at the "develop" branch for future PRs...?

[Rican7]

Wow, thanks @al-the-x! I'm glad you agreed with my suggestions here! :D
This all sounds really good.
And yes, a contributing section is an absolute necessity in my opinion. Unfortunately, however, getting people to actually read and follow it is another thing all together. :P

[brianmuse]

👍

[leightonshank]

I'm glad to see that active development is picking back up on this project! I think this is a great idea, especially to get the version tagging consistent and under control. Having version milestones will also be a big help in sorting out the backlog - little issues and bug fixes get slotted for the next sub-minor release, new features and bigger fixes get put in the next minor release, and then the big hairy ones go for the next major release.

We've been using PHP AR pretty heavily and have just been tweaking our own fork to add/fix things that we have come across since it seemed that development on the project had stalled out for a bit. I'd like help out however you guys need to keep the project active and going, and contribute back whatever I can.