<a href="#" class="seekto" data-time="199">3:19</a> you're actually following semver by choosing 0.4.0, since semver allows breaking changes between minor versions if the major version is 0
@JulieNgTech2 жыл бұрын
Indeed. I meant that even though it's a breaking change, I am incrementing 3 to 4, although strictly speaking, it should be major version, so a 1
@leopignataro2 жыл бұрын
@@JulieNgTech what I mean is that semver agrees with the principle that before 1.0.0 "all bets are off", there's even rules specifically meant to allow that. BTW, do you really find it productive to use git on the command line, or are you restricted from showing a specific GUI client on your videos? I don't normally shy away from the command line, but when it comes to git I find it terrible to get a good grip on the graph without a GUI
@1234minecraft56782 ай бұрын
@@leopignataro using the cli is faster in the most cases, also if you are using custom aliases for some use cases that appear often in your workflow it gets even faster and for the other cases, you could use a TUI like lazygit. Not having to jump between the coding environment and the browser to manage git is much faster than going back and forth the whole time.
@_skyyskater2 ай бұрын
Terrible idea if you plan to do this while in production!
@alpachino468 Жыл бұрын
I wasn't able to watch the entire video yet, so I'm not sure if this is answered: What about really trivial non-breaking changes - say, for example, a text change - would that bump the MINOR number or the PATCH number? This has always stumped me because It's not really a new feature, nor is it a bugfix...
@felipealvarez19826 ай бұрын
stinky feet :) thanks Julie. I stumbled across this by accident. I love your candid and unscripted style! Keep going! thanks. Subscribed.
@JulieNgTech3 ай бұрын
Thank you Felipe ♥️ reading your comment confused me for a second... but then I re-watched and laughed myself. Thank you for the reminder my fast brain is snarky 😅 and that I can be myself 😅
@DominicLondon Жыл бұрын
To be fair to Hashicorp, semver makes special allowances that the major version doesn't have to change on breaking API changes when at 0 [see #spec-item-4]
@grimmersnee Жыл бұрын
this is extremely useful. Thanks a heap
@JulieNgTech Жыл бұрын
Glad it was helpful!
@bandinopla6 ай бұрын
what a great way to start a video "<a href="#" class="seekto" data-time="7">0:07</a>" knowing that you have more important stuff to do and this one is going to be a quickie. Ok, important woman, keep going...
@znk0r4 ай бұрын
Do you have an actual comment on the information shared in this right to the point video?
@JulieNgTech3 ай бұрын
It wasn't intentional 😬 I'm actually a lowly individual contributor in a giant corporation just trying to squeeze in some content for the wider world 🤗 - not just the Azure customers who can afford the program I work for.
@bandinopla3 ай бұрын
@@JulieNgTech and you did it again "...customers who can afford the program I work for" reinforcing your self worth. You feel the need to reassure your professionalism and express how proud you are of yourself to be a cog on a giant machine. You did it, you are hooked into the big corporate machine. Slow clap. You have that pro look/vibe so don't worry about people not getting from you anything other than the feel they are talking to a successful profesisonal. But don't be pedantic, no need to point out or make reference to what you already emanate. Your mom and dad must be proud of you, you did it... now let us, humans, listen to you without looking at the Dorian gray painting showing us how little we have accomplished in life.
@znk0r3 ай бұрын
@bandinopla dude you have some serious issues.
@JoshMelodyMusic3 ай бұрын
I always prefer that kind english, great video
@JulieNgTech3 ай бұрын
Thank you Josh!
@Taragurung15 күн бұрын
1. how can developer determine the changes will break things or not? 2. How to force users to follow the commit standards, one thing that makes me confusing is where the commit fits in , its either chores or fix or bla bla, kind of a long list . How do you do this?
@Antonio-yy2ec Жыл бұрын
Great solution thank you for sharing this video
@JulieNgTech Жыл бұрын
You're welcome!
@julienmelard87752 жыл бұрын
I really miss your videos !
@JulieNgTech2 жыл бұрын
Me too! But good news, more videos coming soon :) Only a few weeks ago I semi-formalized an agreement with work to spend workweek hours on KZbin. In the coming months, you'll see a Cloud Design Series that will teach folks how to think like an architect. Stay tuned!
@bykalim Жыл бұрын
Thank you
@JulieNgTech Жыл бұрын
You're welcome
@isaacfidler4716 Жыл бұрын
So which branch would I run standard-version on to up the version? If its feature-branch > dev > staging > main. Wouldn't I have to run this on a feature branch, and then merge through to main? Dev, staging and main are protected, so I can't commit the new version/change log straight to them? Then it seems like a lot of work to go through all those CI pipelines on my dev and staging branches to change the version. Would I have a new feature-branch like 'increase version' before a release? If I did it straight to main on a merge, then my other branches are behind because of the updated change log, which seems weird? I'm not sure if that makes sense but yeah, just which branch am I running this on, and what's the ideal workflow?
@JulieNgTech Жыл бұрын
Great questions Isaac :) You're right, that is too much work for a change log, which is why I don't strictly use the PR workflow. I generally enable branch protection, but I give myself as admin possibility to bypass it. Generating a changelog is one reason why. I think PRs are good, but don't need to be used 100% of the time. There's a great analogy that forcing your team to always use PRs is like forcing your family through airport security multiple times a day. When you say the other branches are behind, which ones? If it's the feature branches, as part of best practice, you should always grab the latest changes from the primary branch before merging. So for example, if you primary is dev, I would always do `git pull origin && git rebase origin/dev` to grab those changes before merging my feature branch. Does that make sense?
@isaacfidler4716 Жыл бұрын
@@JulieNgTech Yes, thanks very much for replying, that makes a lot of sense. Appreciate it!
@wazz60032 жыл бұрын
Great stuff, thanks!
@JulieNgTech2 жыл бұрын
Thanks Wazz! If you find this useful, please share with your friends and colleagues :)
@wazz60032 жыл бұрын
@@JulieNgTech Will do - keep it up 💪
@errre8091 Жыл бұрын
Great video! This package is now deprecated what are you using now?
@user-tv2kr6oo8p8 ай бұрын
What if I not using node? Does npm is still required?
@rodolfoalbuquerque25352 жыл бұрын
really great stuff! I was looking for insights with semver and pipelines for a while... Althought it clarified some stuff, I'm still thinking what the best strategies for branching and semver would be... maybe a main, with the stable tags and a beta or rc branch with pre-stable tags and an unstable branch. This way I would do PRs from Unstable to Beta and from Beta to main, running testing and tagging on all 3 of them on a CI pipeline and running changelog only on main pipeline... does that make sense?
@JulieNgTech2 жыл бұрын
If it makes sense for you, give it a try. That's the only way you will know if it works - and if it works over time is to build it and use it. Just be aware that the promotion concept you described is straightforward… it's the git branching workflow that we all usu. trip over. The fewest people are that disciplined to be able to manage that many "active" branches - myself included. Anyway, sorry for long delayed response. Did you end up trying it on your own?
@ChandraSays Жыл бұрын
@Julie Ng Thank for the video. Could you do a video/walkthrough of pre-release management, releasing a pre-release and then syncing the released code with dev branch that might have progressed further since the pre-release was cut please? I am not sure if I could articulate the ask well, hope it was clear enough
@JulieNgTech Жыл бұрын
Hi Chandra, sorry for late response. When you say "might have progressed further since the pre-release was cut"… if that was also cut from the dev branch, there shouldn't be any additional changes that need to go back, no? Or are you talking about bug fixes?
@ChandraSays Жыл бұрын
@@JulieNgTech Sorry for the delayed response, yes I am talking about big fixes. Another scenario is, you cut a release branch that goes through some verification/testing/sign-off which could be few days and the eventually gets merged to main branch, changelog gets generated, a new commit is made with changelog/release notes etc. and realeased to public. While this is happening Developers might start working for next release and might have pushed some commits to dev branch. Now when it's time to merge master back to develop, bothe the branches are diverged. I wanted to understand how to handle conflicts specially around change log, package.json etc.
@xmadcode Жыл бұрын
@Julie Ng, Thanks for the video, great content. Is there a way you can share your gitconfig aliases 🙈 ?
@JulieNgTech Жыл бұрын
Yes, of course! They are open source at github.com/julie-ng/dotfiles/blob/main/.gitconfig and if you want you can view all the other dotfiles in the repo :) Enjoy!
@raghur5678 Жыл бұрын
Hi thanks for the video.. i have one problm like when i am running on my feature branch the Tag version is 1.0.1, whn merging with the Develop Branch its getting changed to 271.1.0,but i want to be with 1.0.1 version for the Client SDK and the Data N Service Dll... but why its getting changed? any idea
@JulieNgTech Жыл бұрын
Those types of questions are very hard to answer based on a few sentences. But based on fact that `1.0.1` is very different form `271.1.0` there's a workflow issue here where stuff is happening in parallel and not aligning well. You should be able to see from `git blame` who made what change. Go talk to them and figure out how both your actions and workflows work together. That's just a guess, but talking to people is generally a good first step.
@raghur5678 Жыл бұрын
@@JulieNgTech thankyou for you reply. will do the same.
@markcuello5 Жыл бұрын
HELP
@JulieNgTech Жыл бұрын
🛟
@hiteshrohilla Жыл бұрын
not for noobs like me. unable to understand well.
@JulieNgTech Жыл бұрын
Hi Hitesh, yes, this video is not for beginners. There are other videos on KZbin that probably will work better for you.
@jamesang87357 ай бұрын
Is there a more amateur video..
@gamertechkid14903 ай бұрын
Please use dark theme. White backgrounds make videos unwatchable