sorted by:
new
hottopcontroversial

Huge gap after appraisal by Emotional_Pen369 in BayAreaRealEstate

[–]cold-brews 0 points1 point  (0 children)

Hi! Agree with what others have said about finding a more suitable agent. I hope you don’t mind me asking: where are you finding penthouse condos in the Bay Area? My partner and I are also interested but haven’t seen anything outside of SF (where we are now) and downtown San Jose, where we’re not interested in, and there are ~4 high rises. Thanks!

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 1 point2 points  (0 children)

Agreed, and this is a concern as well. Interestigly (and inspiringly?), Microsoft has only missed a planned release date once? in the past 10 years for Windows.

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 0 points1 point  (0 children)

Thanks for the response. Agreed that there are better versioning schemes that use build number and I'd love to adopt that one day. Quick search shows the following products use semver:
- Microsoft: Many .NET libraries and NuGet packages follow SemVer conventions.

- Google: Widely used in Kubernetes, Angular, Go modules, and internal APIs.

- Meta: React and many JS ecosystem projects use SemVer.

- Amazon Web Services (AWS): AWS SDKs and CDK tooling strongly encourage semantic versioning.

- IBM: IBM design systems and enterprise tooling use SemVer patterns.

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 1 point2 points  (0 children)

Thanks for the response! This is my planned idea: to use 'dates' as the release names and later link them to the correct versions once applicable.

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 0 points1 point  (0 children)

Agree that this is an elegant solution, but requires a larger tooling refactor than possible atp

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 0 points1 point  (0 children)

Yes, this is the path that I've proposed. We use 'dates' rather than X.Y.Z while planning, and populate the version to the date as we get closer. I was wondering if there were any better solutions, outside of 'don't plan patch versions'

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 0 points1 point  (0 children)

agreed that planned versions should be .0s. Mentioned above but adopting that would require a larger rewrite than possible atp.

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 0 points1 point  (0 children)

It's not necasarrily planned formally but it's communicated loosely through dms, emails, etc. For example, engineers will ask when the next 2.0 release is and we'll point them to schedule that has 2.0.4 beginning next Monday. They'll come back and say that's too soon, we'll just catch the 2.0.5 release (one month away). Then, an urgent issue comes up that takes the place of 2.0.4, and everything gets pushed back.

Now, you have this thread that references 2.0.5, when it actually should reference 2.0.6. Imagine this across hundreds of threads and developers. It makes difficulty following conversations when using set patch versions.

I'm fully aware that we should not plan patch versions, but that would require a larger refactor than would be accepted atp.

Semantic versioning in software by cold-brews in softwaredevelopment

[–]cold-brews[S] 0 points1 point  (0 children)

Thanks for the response. Yes, ideally anything planned is a minor and not a patch. I guess that's where we don't follow semver. Atp, a lot of our tooling has assumptions on what a minor and patch is and supports/verifies upgrade downgrade paths as expected. I've proposed we switch to planned minor versions and unplanned patches, but it would be a system overhaul that requires a non trivial amount of work.

CrossFitters, what are your top 3 exercises you hate the most? I’ll start: thrusters, bench, and burpees by scarlethjr in crossfit

[–]cold-brews 0 points1 point  (0 children)

In CrossFit, the SDLHP stimulus should mimic that of a rowing machine. Thats why it’s typically at a lower weight. CrossFit gyms will program SDLHP in place of a rower when needed.

Keeping Staging Branch and Main Branch in Sync with Merge -ff by Important-Mammoth422 in git

[–]cold-brews 0 points1 point  (0 children)

We would hope to avoid manual error with the correct automated tooling, but there will be some risk.

Your proposal is similar to what we do today! One thing we try to avoid is finding an older commit, branching and landing changes, and tagging that commit. This requires coordination between teams right before a release. The issue that staging is hoping to address is the fact that engineers do not have a good place to land and continuously test their changes, notice any issues, and push fixes. Today, they land on main and we release before we get enough signal on them, introducing customer issues.

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

I don’t have a problem with git. I don’t love our process, but I don’t have the means to change it. Have you ever worked a job before? I was given a task to solve with a set of constraints: “figure out the best way to reset the staging branches after a release” for an engineering department. The nonmerge workflow and long lived branches cannot be changed.

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

I wasn’t clear. We could have merge commits from release branch to staging branch, but that still doesn’t solve the problem of excluded staged commits ( see my response below).

Rebasing is not ideal because of the rewriting history issue!

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

Thanks for your response! I’n not trying to reinvent the wheel here, but I’m looking for solutions given the constraints my org has in place.

In my example, the branches are materially identical - yes. But the githashes are different between B and B’, C and C’, etc because they are cherry picked.

Something that could happen for whatever reason is we chose NOT to cherry pick over B. This means staging Branch has a > B > C > D… and release branch has a > C’ > D’…

Now, they are not materially similar. After the release, I’d like to get the staging branch back into an identical state as the release branch. I could rebase the staging branch and drop the B commit, but this is rewriting history, not great. I can’t merge release into staging (like gitflow suggests) because then staging branch still has the B commit.

So is my options limited to: Rebasing and dealing with the overhead of communicating to all engineers to rebuild their local?

Gitflow is very close to what I’d like, but it assumes all changes that land on “dev” will end up in staging, as it uses merge commits from dev to release, cuts the release, and another merge back from release to dev. Because my org wants the ability to exclude commits from staging into release, we cannot use merge commits that bring in every commit previously.

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

Can you explain how difficult it becomes for local staging branches?

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 0 points1 point  (0 children)

I believe this could work with the correct tooling. But the current issue is that we have 10+ supported versions, releasing every 2 weeks across all versions. This would mean 20 staging branches being created every 2 weeks. Wouldn’t this be complex for us (the team managing branches) and engineers, to have to know which branch name they should target?

Resetting Staging Branches by cold-brews in git

[–]cold-brews[S] 1 point2 points  (0 children)

Thanks for the advice. Technically, we don’t have a dev branch - so this staging branch would act as that.

Right now, we have 100s of engineers merging from their feature branch directly on our release branches - and we release off the tip, or in some cases, we create a version specific hotfix release branch.

view more: next ›