There are no hard set rules, and it depends on what uses you have for the build number.

Making it a monotonically increasing number helps with versioning because it’s trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It’s not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.

You sound like you’re focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.

Remembering ActiveX Controls, the Web’s Biggest Mistake:

Running JavaScript everywhere is looming as one of the biggest screwups in InfoSec. What do userscript extensions like Grease monkey teach us?

Ah, the Microsoft tradition of always having the wrong priorities.

I wouldn’t be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

Agile is not a system. It’s a set of principles, set by the Agile manifesto.

The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.

I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .

Also interesting, successful software projects don’t just finish and die. They keep on going and adapt changes and implement new features. If we have a successful project that goes on for a decade but we have a clusterfuck of a project which blows up each year for the same time period, by this metric you’ll have only a 10% success rate.

If you write it down it is documentation.

I think you’re not getting the point.

It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.

Requirements are not the same thing as specifications either, but both are documentation!

https://en.wikipedia.org/wiki/System_requirements_specification

that managers want to stay in control of everything, and they decide whether they do it or not.

That’s fine, it’s a call from the manager.

That doesn’t make it Agile’s fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.

So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.

I think you’re confusing documentation with specification.

Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.

Requirements drive the project. Documentation always lag behind the project.

the whole point of agile is to be short term

Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.

This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.

Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.

The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

I think you got it entirely backwards.

The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.

The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.

Note that this is failure to deliver on time, not failure to deliver full stop.

It’s also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It’s easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.

On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.

I don’t think this is an Agile thing, at all. I mean, look at what Agile’s main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.

I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.

The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.

It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.

It baffles me that you can advertise something as “unlimited” and then impose arbitrary limits after the fact.

I didn’t saw anything on the post that suggests that was the case. They start with a reference to a urgent call for a meeting from cloud flare to discuss specifics on how they were using the hosting provider’s service, which sounds a lot like they were caught hiding behind the host doing abusive things,and afterwards they were explicitly pointed out for doing abusing stuff that violated terms of service and jeopardized the hosting service’s reputation as a good actor.

First communication, because they clearly were confused about what was happening and felt like they didn’t have anyone technical explain it to them and it felt like a sales pitch.

I don’t think that was the case.

The substack post is a one-sided and very partial account, and one that doesn’t pass the smell test. They use an awful lot of weasel worlds and leave about whole accounts on what has been discussed with cloud flare in meetings summoned with a matter of urgency.

Occam’s razor suggests they were intentionally involved in multiple layers of abuse, were told to stop it, ignored all warnings, and once the consequences hit they decided to launch a public attack on their hosting providers.

it’s about deploying multiple versions of software to development and production environments.

What do you think a package is used for? I mean, what do you think “delivery” in “continuous delivery” means, and what’s it’s relationship with the deployment stage?

Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

https://wiki.debian.org/DebianAlternatives

Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.

I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian’s .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It’s not rocket science. In contrast, these tricks sound like overcomplicated hacks.

Logging in local time is fine as long as the offset is marked.

I get your point, but that’s just UTC with extra steps. I feel that there’s no valid justification for using two entries instead of just one.

Any style guide is better than no style guide. Until a better option is presented, something is better than nothing.

The Philosophy section has quite a few wonky arguments; I’d skip it altogether.

I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.