search

richardmiller-zz / BehatSpec

Extensions to integrate Behat and PhpSpec
MIT License
51 stars 6 forks source link

Todo #13

Closed pocky closed 7 years ago

pocky commented 7 years ago
richardmiller-zz commented 7 years ago

I've created https://github.com/richardmiller/BehatSpecExtension as an empty repository. We will need to put at least a composer.json file in to be able to register it on packagist

pocky commented 7 years ago

@richardmiller done. Packagist : rmiller/behat-spec-extension

ek9 commented 7 years ago

Hey guys, I'd like to help with some PRs. Some questions:

  1. Do I issue PRs against this repository or against the new one (https://github.com/richardmiller/BehatSpecExtension) ?
  2. Do I issue the PRs when brancing out of of branch in https://github.com/richardmiller/BehatSpec/pull/12 or do I use the master branch?

If you could answe the above, I will push a PR with what I can do from the checklist. As I understand the main tasks, regarding the subtree split will have to be done by you. As it would overwrite the current repositories, may I suggest to do so in such a manner that the current history of the current repositories is preserved? Otherwise, you would beak compatibility with older versions of your packages. For example any packages that depended on older version will fail to install now. To solve this, I would suggest to:

The downside of this that you might need a package renaming, and that might be problematic. Unless you would consider also moving this under a github organization (i.e. something like BehatPHPSpec) where you could house all the packages.

Anyway, let me know regarding the initial questions so I can send some PRs. Thank you, and thanks for great extension.

richardmiller-zz commented 7 years ago

@ek9 My understanding is that PRs will be to this repository. Anything that needs doing to enable the split will want to be based off master, anything that will follow will want to be based on #12. @pocky is this correct?

@pocky what needs doing with the scrutinizer badges? Will we want to just use scrutinizer on the whole monorepo rather than the individual ones? I'm happy to just remove the badges for now if that's the quickest way of making progress.

ek9 commented 7 years ago

Just my 2cents, things as badges are optional and secondary thing. We should just get multirepo thing working today, so it's functional, then we can just sort out the rest and release. It's hard doing any of the tasks above, when everything will change due to multi-repo. Can we first push all the files to one repository and make sure it is working?

Then before you release we can sort out the badges and any other non-functional stuff. For me it feels wrong that actual features are getting delayed, because half of that todo list is either cosmetic changes, or something that can be done within next hour or two, but we can't do it, because we don't know how the end setup will work.

pocky commented 7 years ago

@ek9 My understanding is that PRs will be to this repository. Anything that needs doing to enable the split will want to be based off master, anything that will follow will want to be based on #12. @pocky is this correct?

True. We works in BehatSpec and SubtreeSplit do the rest.

@pocky what needs doing with the scrutinizer badges? Will we want to just use scrutinizer on the whole monorepo rather than the individual ones? I'm happy to just remove the badges for now if that's the quickest way of making progress.

Just create a new project on scrutinizer for BehatSpecExtension and update badges or remove them.

@ek9 The real job is in all composer.json. We need to update to use self.version on BehatSpec and update dependencies in each composer.json on extensions to 0.4. Just give me an hour ;).

@richardmiller I don't see rmiller/behat-spec-extension in packagist

richardmiller-zz commented 7 years ago

@pocky thank you, I've merged that PR and I've added rmiller/behat-spec-extension to packagist.

pocky commented 7 years ago

@richardmiller Ok, now you need to register in SubtreeSplit with your github account and split with tag : 0.4 (for all repositories). It's time to ping @Nyholm ;)

image

pocky commented 7 years ago

@richardmiller oups forgot to update Readme and "Installation"

Edit: It's ok :)

ek9 commented 7 years ago

Ok, the recent updates make it more clear to me. Also the rebase on #12 part is ment for rebasing the #12 PR based on the master. I first thought it's the opposite way around.

Once subtree split is setup, it will overwrite what is in the repositories. That means all the tags and previous version information will be gone.

Before merging #14, I believe you should tag the current release as something like 0.3 or 0.4, so all your extensions are also released under the new version first, which is compatible to be updated for old users. This will allow any existing users update first.

Then after merging #14, bump the version one more (so 0.4 or 0.5, or I would even consider jumping to 1.0 as a clear indication of bigger changes). If you skip this step and first merge #14, then it you will loose any tags of pre PhpSpec3 version and will sort of break back-wards compatibility for any existing users, who are using the current (older) versions (pre subtreesplit/phpspec3). Some users will not be able to update to PhpSpec3 version, and that will cause their composer install/update to fail, because it won't see any older versions in packagist anymore. And there will be no way to tag them, because git history on the extensions will be gone.

pocky commented 7 years ago

@ek9 Right

That's why there is two "split" step in the checklist. First for current version with all fixes (#11) related to Behat ^3.0 (current master — release as 0.4) and second for PhpSpec ^3.0 (#12 — release as 0.5).

My problem with 1.0 is the lack of tests and I think we need to work on it before the first major version 👻.

ek9 commented 7 years ago

Just to clear things up:

  1. The tags for current version (before any new MRs are merged, even #12) should stay within similar range as current versions (so <1.0). This is to keep backwards compatibility.
  2. The 1.0+ should only be used for any post #12 releases.

You don't have to tag the new version, you can use branch-alias in composer.json:

"branch-alias": {
    "dev-master": "1.0.x-dev"
},

This would make the master 1.0.x-dev version, so you don't tag that. It's only important that you tag the current version for backwards compatibility. Anything that is newer (e.g. #11 and #12) can be worked on before you tag those releases and we can add tests and do final tweaks before the release.

You could also tag something like 1.0.0alpha1 if you want to use a tagged release, which can later be removed when 1.0.0 is there.

richardmiller-zz commented 7 years ago

Agreed that we are not ready for 1.0 straight after sorting the split. As well as the additional tests it would be good to get it to use Behat 3.2 which should remove the need for the ErrorExtension and simplify things a bit, as well as dealing with some errors better than it does currently.

pocky commented 7 years ago

@ek9 You look better than us on the "release" subject :D. BTW only @richardmiller can do this (I don't see BehatSpec on SubtreeSplit because it's not an organization).

Richard, we need you ;)

richardmiller-zz commented 7 years ago

Hello, what do I need to do? :)

pocky commented 7 years ago

@richardmiller

  1. Tag current master as 0.4
  2. Register on Subtreesplit with your github account
  3. Split BehatSpec with "Push tags to slaves" option (path for slaves are src/Extension/name-of-extension)
  4. Merge #12
  5. Tag as 0.5
  6. Split
  7. Update composer.json on master with branch-alias

@ek9 are you okay with this or branch-alias should be added on current master before step 1? @Nyholm looks good for you?

Thank you to all of you 🤘

ek9 commented 7 years ago

@pocky I think your list looks good. Regarding branch-alias it was just a suggestion, I don't think it's really necessary, it all depends on how you plan to do future development and can be deicided upon later.

richardmiller-zz commented 7 years ago

@pocky @Nyholm I tagged current master as 0.4.0 and registered on https://www.subtreesplit.com/. I couldn't see a way to do an initial split so I've tried tagging 0.4.1 but that doesn't seem to have triggered a split either.

@Nyholm btw, it did not show all my repos on the project configuration page, I guess it hit the limit of the number of repos returned by github's API and this was an issue because it's my personal account so has a lot of forked repos in it. I deleted a load of old forks to work round it so not an issue for getting this split done now.

Nyholm commented 7 years ago

It is pushes to the master that triggers subtreesplit. I listen to the github push event.

I guess it hit the limit of the number of repos returned by github's API

Probably, thank you.

richardmiller-zz commented 7 years ago

@Nyholm Ah cool makes sense, thank you

@pocky @ek9 I've done the above apart from the branch-alias. Had to make a few empty commits to force the split when I'd only pushed tags.

pocky commented 7 years ago

@richardmiller @ek9 @Nyholm 🎉 profit 🎉

ek9 commented 7 years ago

I'll test the setup later, and send some PRs / let you know if there are any problems.

Good job and nice cooperation! 👍

ek9 commented 7 years ago

I was checking backwards compatibility, and I am wondering if this will cause problems (this is an old build that depended on phpspec2), now installs the following versions:

Are 0.4.1 version of extensions compatible with phpspec2?

ek9 commented 7 years ago

Although, I've fixed in the package by providing proper (old v0.2 versions which are still available as git release), so this is sorted for now. As you are using 0.x.y versions, I have locked them to use old 0.2.* instead of ~0.2, so it's a problem on my end that I fixed.

ek9 commented 7 years ago

Although now looking at the readme, if you want people to use 0.4 of BehatSpec, you also have to set version requirements for the extensions, so they use 0.2.* instead.

richardmiller-zz commented 7 years ago

Thank you for checking this, do we just need to add a note on this to the installation instructions then?

heregiam commented 7 years ago

Firstly great job to you all for making this really useful extension work with phpspec 3.

I've tried it out this morning, and I think there might be a tiny change needed in README.md for specifying the classes in phpspec.yml and behat.yml.

I believe instead of: RMiller\BehatSpec\BehatExtension and RMiller\BehatSpec\PhpSpecExtension they should be: RMiller\BehatSpecExtension\BehatExtension and RMiller\BehatSpecExtension\PhpSpecExtension

ek9 commented 7 years ago

Thank you for checking this, do we just need to add a note on this to the installation instructions then?

Well, one thing that we could do is add specific versions to the composer.json of the older version of BehatSpec. So a 0.3 series, could require 0.2.* version of extensions. That way it would be sorted out by composer, as it will install the required versions.

ek9 commented 7 years ago

I've made a separate issue for this as I believe this big "TODO" can be closed. We can sort out the rest by opening separte issues once things come up :) For backwards copmatiblity check: https://github.com/richardmiller/BehatSpec/issues/16

pocky commented 7 years ago

@heregiam Is it possible to open a dedicated issue? I want to specify issue in PR for tracking and #13 is already big ^^.

Thanks