• 0 Posts
  • 18 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle
  • I remember using Mosaic on Silicon Graohics machines back in the early ‘90s. It’s was fab for the time.

    And yes, Mosaic became Netscape, became Firefox. From the wiki page at https://en.m.wikipedia.org/wiki/Netscape_Navigator

    The business demise of Netscape was a central premise of Microsoft’s antitrust trial, wherein the Court ruled that Microsoft’s bundling of Internet Explorer with the Windows operating system was a monopolistic and illegal business practice. The decision came too late for Netscape, however, as Internet Explorer had by then become the dominant web browser in Windows. The Netscape Navigator web browser was succeeded by the Netscape Communicator suite in 1997. Netscape Communicator’s 4.x source code was the base for the Netscape-developed Mozilla Application Suite, which was later renamed SeaMonkey.[4] Netscape’s Mozilla Suite also served as the base for a browser-only spinoff called Mozilla Firefox.










  • It’s a great analysis, and I don’t disagree with anything you said (mostly because you’re better informed than I am). But you nailed it with “Why would I need this? I don’t know yet.” It should all be driven by need—the fact their are more options is great, but doesn’t mean they should be used just because they’re there… For many hobbyists, ease of access and speed to get started is the main driver, and for those cases, pre-built boards are the answer.

    I remember talking to a car manufacturer in the early 2000s who said it would be relatively easy to make cars to a custom length / load space. But they tend to make specific models because if you give people too much choice, they get paralysed and don’t choose anything.

    I suspect it’s not quite that simple but the principle seems sound.





  • We’ll of course it depends on the scale of the changes. Depending on how your calling them, the version could be in the url, such as zooms api including /v2/ in the urls. Then you can introduce /v3 with many changes whilst leaving /v2 in place for some amount of time.

    If /v3 also means a complete change of database and other underlying infrastructure (eg removing the concept of a zoom meeting), then you’ve got different challenges. Those are probably about overall design, not api.


  • One approach I’ve seen (from a user pov, not dev, so I’ve no idea of the code bloat it might cause) is to pass the API version number in the call. Then your api can be backwards compatible for 2 or 3 versions, giving other users time to upgrade their code. It de-couples things to give you all a bit of slack for both rapid iteration and stability.

    But it also depends on the ‘contract’ between you and the users so be very clear how long / how many versions will be available. Probably will involve a ‘use by’ date.