Comments (5)
I know these are arbitrary names and opinionated, but my 2 cents (Dollarydoos !).
master
never made sense. We literally use the branch
command all the time and branches come off a trunk
We develop in our feature branches, but then attempt to merge multiple features into the staging
area.
So my vote is for trunk
and staging
with all feature branches to originate from staging
and staging
being the only one that merges to trunk
to be tagged as a release.
from skeleton.
Ha, <3 Dollarydoos.
Sounds like you've used Subversion in the past?
http://guides.beanstalkapp.com/version-control/branching-best-practices.html
I may be revealing some ignorance on my part, but this is the first I've heard of this paradigm! Makes the UX part of my brain start throwing some red flags on whether casual contributors these days will understand this.
As with many things in Skeleton my inspiration here is Mantine:
https://mantine.dev/pages/contributing/#git-branches
https://github.com/mantinedev/mantine/branches
Also I'm lazy, so typing dev
is shorter :)
from skeleton.
Heh, try CVS and then svn shudder
Nah, mainly from Github/Gitlab Flow paradigms:
https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy
https://www.flagship.io/git-branching-strategies/
I do like having that safety net of merging back into staging before some CI/CD shoots it straight out to S3/GitHub Pages. Our current situation right now seems like a good example - we have docs with A11y content updates, but also a mass rename of all docs pages due to SK.next.409 and the actual Skeleton lib updates that affect the doc functionality in two separate feature branches, but if we were to merge them to trunk before we release the actual package to npm, that wouldn't be cool. And considering that the testing covers looking at the same pages, it would be a waste of time to do it once for each feature branch to verify when it could be all merged to staging for a final single look over before releasing it in tandem with the npm package.
But then again, we don't have CI/CD yet, so keeping it as simple as possible is fine by me too!
from skeleton.
That's interesting. Yeah I think as we continue to grow things will evolve more and change. Given the limited staff and resources we're probably best to go with the simplest option. So we'll use the dev branch as mentioned in the OP. But I would like to read more into this going forward. Thanks for sharing Nik!
from skeleton.
The branch is live and includes various updates to the documentation. This includes details for targeting the dev
branch for all PRs going forward. I'll echo this info on the Discord as well.
from skeleton.
Related Issues (20)
- Disabled state HOT 1
- installation instructions for next recommend a deprecated package HOT 1
- NEXT: Resolve regressions in the component unit tests HOT 2
- NEXT: Resolve global focus states for native elements and Zag-based components HOT 7
- NEXT: Update Svelte/React packages to utilize PNPM Catalogs for version syncing HOT 1
- NEXT: Improve the default SVG images for the Ratings component
- NEXT: Contributor component documentation should cover Zag.js integration
- NEXT: Implement Zag-based animations for the React Accordion component
- NEXT: Review options for sharing and maintaining common component data between frameworks
- Theme Generator myCustomTheme HOT 7
- NEXT: investigate Vike for use in our sandbox apps HOT 6
- Code Blocks skeleton v3 HOT 2
- SvelteKit Tailwind’s layers src: url | skeleton v2 & v3 | SvelteKitError: Not found: /assets HOT 6
- Hotfix: Restore v3 Navigation Docs
- dark-mode | make style changes when OsPrefers and UserPrefers change HOT 1
- Is the selection prop in RecursiveTreeView reactive? HOT 4
- NEXT: Custom Progress Animation Not Optimal
- NEXT: React package has `react` and `react-dom` as deps instead of peerDeps
- Text in total field for paginator HOT 1
- Custom Fonts documentation guide to Preloading fonts affects performance and SEO drastically HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from skeleton.