LEGACY REPO. This repository is for maintenance of the legacy LitElement library. The LitElement base class is now part of the Lit library, which is developed in the lit monorepo.
This benefits everyone involved with the repos: users, maintainers/developers etc.
What
Branches that correspond to trailing "major" releases where all patches/minor updates for those releases could be found; E.g.
Example branches:
1.x.x
2.x.x
etc.
Note: With this additional approach the 'main' branch is occupied by the latest "major" release (and it's patches etc.).
Additional reasoning
Managing release branches is not a fun thing to do, and I admit, is extra work however with new development paradigms/approaches coming up all the time, in the frontend world, troubleshooting becomes a thing that more and more people have perform on their respective projects. Having these release branches would offer us an additional way to inspect different release sets directly from a branch. However, if release tagging (#1200 ) is kept in sync with releases made to npm this ticket is unnecessary.
Why
This allows users to be able to quickly see how things work in a specific major release without having to wade through all the listed branches, change commits etc..
Functional description of task/subtask
Create a branch for all trailing "major" releases where all patches can be merged into/maintained.
Acceptance criteria
A branch is created for the 2.x.x version line of the library where all it's minor, and patch, updates are kept.
Request: major/minor branches for ref
Who
This benefits everyone involved with the repos: users, maintainers/developers etc.
What
Branches that correspond to trailing "major" releases where all patches/minor updates for those releases could be found; E.g. Example branches:
1.x.x
2.x.x
Note: With this additional approach the 'main' branch is occupied by the latest "major" release (and it's patches etc.).
Additional reasoning
Managing release branches is not a fun thing to do, and I admit, is extra work however with new development paradigms/approaches coming up all the time, in the frontend world, troubleshooting becomes a thing that more and more people have perform on their respective projects. Having these release branches would offer us an additional way to inspect different release sets directly from a branch. However, if release tagging (#1200 ) is kept in sync with releases made to npm this ticket is unnecessary.
Why
This allows users to be able to quickly see how things work in a specific major release without having to wade through all the listed branches, change commits etc..
Acceptance criteria
A branch is created for the 2.x.x version line of the library where all it's minor, and patch, updates are kept.