Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark setting of root directory as deprecated #571

Merged
merged 2 commits into from
Dec 8, 2019
Merged

Mark setting of root directory as deprecated #571

merged 2 commits into from
Dec 8, 2019

Conversation

mvz
Copy link
Contributor

@mvz mvz commented Aug 27, 2018

Summary

Setting root_directory will no longer be supported in 1.0.0. Mark it as deprecated in the cucumber scenario.

This was originally the main pull request for #598. Original description follows

Summary

Update the still development branch so the change to master is no more than a removal of deprecations.

Details

This is a work in progress. This is a combination of backporting bug fixes, moving deprecated code, moving other files. The end goal is that merging still into master will only lead to conflicts in deleted files that contain the code deprecated in the 0.14.x line and removed in 1.0.0.

Motivation and Context

A lot of projects that use Aruba are not even on 0.14.x yet. We should be able to tell them that they should do that and fix all deprecations, and then they should be able to safely move to upcoming 1.0.0. Since there are still reasons why projects are stuck on pre-0.14 versions, these reasons should be taken away first. This means Aruba development is stuk on 0.14 for a while longer as well. To avoid duplicate effort, still and master need to be made as similar as possible.

We may have to revert some breaking behavioral changes between still and master eventually, as well as some deprecations.

How Has This Been Tested?

CI. I'm hoping to add AppVeyor to the still branch as well.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactoring (cleanup of codebase without changing any existing functionality)
  • Update documentation

Checklist:

  • I've added tests for my code
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

@xtrasimplicity
Copy link
Member

This is a great idea, @mvz! Shout out if you'd like a hand and I'll see what I can do. :)

@stale
Copy link

stale bot commented Oct 26, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

@stale stale bot added the stale These issues were closed by stalebot and need to be reviewed to see if they're still relevant. label Oct 26, 2018
@xtrasimplicity xtrasimplicity added slow burner and removed stale These issues were closed by stalebot and need to be reviewed to see if they're still relevant. labels Oct 27, 2018
@mvz mvz force-pushed the unify-branches branch 7 times, most recently from 01e0f59 to 2e0a1ed Compare February 1, 2019 15:01
@mvz mvz mentioned this pull request Feb 27, 2019
12 tasks
@mvz
Copy link
Contributor Author

mvz commented Feb 27, 2019

I'm going to move parts of this to separate pull requests, to be coordinated by #598.

@luke-hill
Copy link
Contributor

What's the benefit of these 2 branches and why don't we just have 1 master branch?

Is it because we're supporting a 1.0 and 0.9 based development, if so could we not rename the 0.9 branch as something like 0_9_stable (Akin to rails). And have the 1.0 stuff on master

@mvz
Copy link
Contributor Author

mvz commented Apr 29, 2019

Yeah, 1.0 stuff is on master and 0.14.x stuff is on still. The original plan (from before my time) was to have a 1.0 version a lot more quickly, but a lot of projects that use Aruba are still not even on 0.14.x.

Sooo ... I'm first going to focus on helping them upgrade and fixing stuff in 0.14.x for that.

But since I don't want to keep forward-porting bug fixes between these two branches, I want to get to a point where I can at least merge still into master regularly.

Renaming still to something else would be fine.

@mvz mvz force-pushed the unify-branches branch 2 times, most recently from 0c5bb44 to 32486af Compare May 19, 2019 19:29
@mvz mvz force-pushed the unify-branches branch 2 times, most recently from 5dd7a0c to a283172 Compare May 31, 2019 14:09
@mvz mvz force-pushed the unify-branches branch from a283172 to 67ac579 Compare June 16, 2019 10:02
@mvz mvz changed the title Move to unify still and master branches Mark setting of root directory as deprecated Dec 8, 2019
@mvz
Copy link
Contributor Author

mvz commented Dec 8, 2019

This is now only a documentation change. Merging.

@mvz mvz merged commit 181a54c into still Dec 8, 2019
@mvz mvz deleted the unify-branches branch December 8, 2019 10:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants