V2 Release

[tig]

This is the master Issue for the "Final" Terminal.Gui v2 Release.

When we do the final merge to v2 from v2_develop to Release v2, that PR will be titled "Fixes #3489. Launch Terminal.Gui v2".

[dodexahedron]

These issues are fine for general talk, but right now the rest of it is backward.

Milestones are for milestones and projects are broader, and can use milestones in organization and display of items in the project.

For example, just one project for V2, and then milestones for Alpha, Beta, Release, and any others that may come up along the way.

Milestones are almost glorified tags, but they have first-class application on the repo main page as well as for organization of items in projects. Milestones also often get used for when there's specific new feature work.

Basically, every organization should have projects, and fewer open projects than the number of repositories they have, since Projects are also a cross-repository entity and thus can have issues in them from one or more repositories in the org

And then every repository should have milestones for times when there will be multiple issues directly relevant to that same body of work. Milestones are repo-local.

[dodexahedron]

Then you can optionally add Milestone as a group-by item in Project views.

[dodexahedron]

To relate that terminology to Jira, if you've ever used that, Milestones are "Epics"

Projects are Jira "Workflows."

[tig]

These issues are fine for general talk, but right now the rest of it is backward.

Yep. Thanks for pointing this out.

Milestones are for milestones and projects are broader, and can use milestones in organization and display of items in the project.

For example, just one project for V2, and then milestones for Alpha, Beta, Release, and any others that may come up along the way.

Done.

LMK if you have more feedback on this.

[dodexahedron]

I like how that's shaping up. :)

My only particular comment as far as the project goes is that it would be good to have at least these two:

• V1 Maintenance
• V2 Release (the one you already revamped - just renamed to be for V2)

The analogy I gave to relate it to Jira is not perfect, because Jira doesn't really have the specific kind of separation of the concepts of a repo and project that github does (which sorta makes sense, since Jira isn't, itself, a source control system).

Typically, on GitHub, you'll have the organization (gui-cs in our case).
That organization is just all the "stuff" that may or may not be directly related to each other, but which share a common "owner."

Organizations have repositories. At the basic level, they're merely git repositories. But GitHub provides a lot more, as a full project management platform. Issues belong to repositories and cannot exist outside of one.

Projects are long-term collections of work related to a common goal.
Projects can and often do include issues from multiple repositories which the organization either owns or has sufficient access to (if external).
Repositories have no concept of projects, innately. The linking is from project to repository, not the other way around, which may not be obvious since repositories show a Projects tab.

So, for us, the projects above are probably a good basic layout.

Milestones belong to repositories. Issues can link to a milestone defined for the repository the issue belongs to.

The milestones you made look pretty good to me, at the moment. If and when we have large development efforts that span more than one issue, that's when we'd throw up a new milestone. Once all work for a milestone is completed, the milestone is also closed.

Issues themselves belong to repositories. They can link to one or more projects, and can link to one milestone. They can have different statuses in every project they link to, so they can be appropriately classified for the purposes of each project.
Once closed, GitHub will automatically set the status of that issue to the designated closed status for all projects it is in.

So, to summarize a standard layout of things, we would have these projects:

Currently (3 projects)

• V1 Maintenance
• V2 Initial Release
  • Name is of course flexible but the intent is that it is for initial release.
  • Closed upon release of 2.0
• VNext
  • Again, naming is flexible, and mostly depends on how we want to triage things for the roadmap.
  • This is a place that stuff that we want to do or explore in the future, but not for V2 RTM.

After V2 is released (4 projects)

• V1 Maintenance (same project - no change)
• VNext (same project - no change)
• V2.0 Maintenance
  • Name just needs to be indicative of what it contains, which is primarily bug fixes, but can also be things like performance enhancements that do not change runtime behavior.
  • Anything here isn't supposed to be a breaking change, unless it's for reasons of a heinous bug that made it through alpha and beta. Although I'd still tend to argue something that big warrants a new major version, under SemVer.
  • This is where issues anyone submits against V2.0 go.
• V2.1
  • Name dependent on how we want to version things. Since we're SemVer, this would mean a feature release without breaking changes on top of 2.0.
  • New issues filed and slated for inclusion in that release go here, as well as anything from "VNext" that we decide belong in this release (they just get added to this one and removed from the other).

Of course more are fine.

As for milestones, post-release, those would generally be for features associated with the next minor version, and there may very well be times when there aren't any around, if we don't have anything formally taped out yet.

[dodexahedron]

As for the current state of the project currently defined, I did add an additional status that helps differentiate between issues that are closed because they were work that has been completed vs issues that are closed for other reasons like cancellation, abandonment, change of direction, obsolescence, etc.

Some projects split that out more granularly, but I don't really think we need to bother with that. It's easier just to have an optional field for the reason, if you wanted to track that specifically.

In any case, it's looking a LOT better and the suggestions in the above comment are actually pretty painless since you can just copy the project to create any of the new ones and then tweak the copy as necessary.

[dodexahedron]

Also note that github actions/workflows can be set up to automate stuff to your heart's content.

You can have it auto-assign newly-posted issues to a specific project (that can also be done in issue templates), trigger automatic branch creation on assignment to specific projects, update status badges, and all sorts of goodies, should anyone want to bother with any of that.

[dodexahedron]

Oh and of course feel free to modify the name/description/etc of the new status label I added to the project. I tried to follow your nice little scheme of emoji + name. (I'm probably going to adopt that for internal projects at work, too. Nice.)

Another common name for that label is "Declined" and it was basically a coin toss for me between that and what it is currently.

[dodexahedron]

I also usually include status labels like one for Paused/Hold/etc, which is used on issues that have been worked on but are on hold for some reason, so there's a much better picture of where active development work actually is happening.

Most of the internal projects at work have that and an optional field with the reason for or nature of the hold (like blocked, developer priorities, etc), which is sometimes handy for example when triaging work items.

I also often like to have optional fields for specifying the PR/Issue number (issues put PR number and PRs put issue number). That's a cleaner and github API queryable way of associating things, especially for something like this repo, where most contributors will not be an org member with write access to the repo and thus can't link their dev branch to the issue.

[tig]

I took your input above and mostly did it.