php-activerecord
php-activerecord copied to clipboard
jpfuentes2
Discussion: Version Tags
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.
A few suggestions:
- v1.1 a3c4601257b026bf3ebbe19f25ec9c8ad3220f6f - 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 d6c4b929769d2d49f7af6d16ed9b68f94af9fed0 - 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. :)
@jpfuentes2 Make this man a contributor already...! I agree with all these suggestions...
Made this issue into a "discussion" ticket... Maybe @kla can give us a similar label for these items?
@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?
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.
@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. :)
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)...
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".
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).
I tagged those commits you suggested, @Rican7 and pushed to the repo. With the closure of #298 and all passing tests (including skipped :poop:), 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...?
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
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.
Great to hear, @leightonshank, and thanks for sticking with it. Love to see your tweaks make it into some PRs...! ;)
So....... I think we should start 1.1 beta TODAY. And in general there can always be a (current version + 1) in active development as an open branch. We can then start testing and adjusting PR's to that branch.
There can be a milestone v1.0 branch that we set as the latest stable and non-api breaking release.
We can always assume that the current master branch version can be merged into the beta branch, while the beta branch may have API changes and such, while v1.0 will only support bug fixes. Because as of now it's been ~3 years and there's a lack of much needed development because of being trapped in v1.0, plus soo many open issues that it hurts! :p??
Like, I'm a little confused as to why things are separated into 1.1 and 1.2 when in general there's a lot of timidness in regard to even creating the 1.1 branch!
Thanks for the kick in the butt @anther. Personally, I've been swamped with work and haven't had as much time to devote to the project, but I'll try to carve some out this week and next. There are a couple of PRs that should really get merged in to constitute v1.2, IMO. Maybe we should open a specific ticket for that discussion?
Ahem... Could we maybe have one more tag? Please? Especially, since you have fixes for PHP7 issues lately, issues that present in 1.1.2.
@TiGR I have been updating #430 the past few days, and started on an updated documentation (preview here: https://koenpunt.github.io/php-activerecord/api/), so maybe that's something we can release. But for now I've released master as v1.2.0: https://github.com/jpfuentes2/php-activerecord/releases/tag/v1.2.0
