Prepare for 1.0 development

[rkeithhill]

As we prepare a space to work on the 1.0 version, I highly suggest we not use master after all the crap I got about master not reflecting the state of what's shipping. :-)

How about we create a develop branch to do 1.0 work on? As we have to fix issues in 0.7.0, we can do that on master as I suspect the changes for 0.x from here on out will be minor. Thoughts?

[dahlbyk]

I think this is two separate issues:

1. Folks landing here and reading a README that's not for their current version. Maybe we should add a line directly under Notes along the lines of:

   This README applies to development toward v1.0.
   Past versions: v0.7

   Which would then be updated after our next release:

   This README applies to development toward v1.1.
   Past versions: v1.0 v0.7

   (In theory the README shouldn't change between bug fix releases.)

2. What's our branching strategy going forward toward 1.0, and what should GitHub's default branch be? Issues/fixes/features that are incompatible with PowerShell v2 seem likely to be the exception rather than the norm, especially at first, so I think you're right that we should keep master aligned with v0.x until v1.0.0 is ready. At that point we can move master to maint-v0.x or something, develop to master and eventually spawn a new develop branch to collect breaking changes for v2.0.0.

[rkeithhill]

1. Sounds good although I think it is OK to tweak the readme as long as the information applies to the current version. For instance, I think it would be OK to add a coverage badge if we ever get that going. Or if there's a typo - OK to fix the typo. Not OK to start documenting features of the version under development (my bad).

2. Check!

[lzybkr]

I think it's common for contributors to start from master, so as they diverge, you'll get complaints about that too.

I guess my point is pick who you optimize for - contributors or users.

[JayBazuzi]

The more often we ship, the less of a problem this is.

[rkeithhill]

@JayBazuzi Unfortunately when you have an all volunteer project, the ship schedule is highly dependent on the schedules of folks doing the work in their free time. :-) And some of us are um, a bit over-committed to several OSS projects.

I'm bouncing between posh-git, the PowerShell extension for VSCode, PowerShellEditorServices, Plaster and a newly started PlasterBuild repo. Oh, and I still need to finish up my impl for EscuXXXX to insert Unicode chars in a PowerShell double-quoted string in the PowerShell repo. So much fun stuff to work on, not enough time.

All that said, I'm hopeful we can be more responsive to bug fixes on the released version. But I have no idea how long it will take us to get 1.0 out with PowerShell Core / ANSI sequence support.

[rkeithhill]

@lzybkr I think this module has enough users coming here for help that I'd prefer to optimize for them.

[rkeithhill]

Another thing to decide for 1.0 development is what minimum version of PowerShell we support? I say we definitely drop v2 support but should we consider dropping v3 and v4 as well?

[dahlbyk]

think this module has enough users coming here for help that I'd prefer to optimize for them.

💯

Another thing to decide for 1.0 development is what minimum version of PowerShell we support? I say we definitely drop v2 support but should we consider dropping v3 and v4 as well?

A good first step would be to make a rough list of the changes you'd make if we could jump straight to supporting only v5+. And even if we dropped v3/v4, we would still be constrained in some of our features (e.g. the proposed ANSI escape sequence). I know we've had to make a handful of concessions in the name of v2, but I don't recall any that were egregious.

For my part, I've spent more time here in the last two months than I really should have, so I'll need to dial back for a bit other than keeping up with bug reports/fixes for this new release.

[rkeithhill]

@dahlbyk Are you OK with me creating a develop branch to do some preliminary work on 1.0? Or feel free to make it yourself.

[dahlbyk]

develop created and marked as protected.

[rkeithhill]

Initial PR #427 submitted. RE:

A good first step would be to make a rough list of the changes you'd make if we could jump straight to supporting only v5+.

I open a separate issue/discussion to track this.