45 Matching Annotations
  1. Last 7 days
    1. 巢狀結構,可以建立多層筆記本分類(雖然這樣做不一定比較好)一則筆記可以放入多個筆記本!


      後記 Update: I tested it and confirm the note is referred to by link. So, changing the note will update it for all notebooks the note is under. 經我測試,確認是一份筆記內容,多個連結。

    2. 不過 UpNote 的版本備份預設不是無限的(可以手動修改),預設會記錄最近的 50 個版本。


  2. Nov 2023
  3. Oct 2023
    1. When content underlying a DOI is updated, we recommend updating the DOI metadata and, for major changes, assigning a new DOI. For minor content changes, the same DOI may be used with updated metadata. A new DOI is not required. For major content changes, we recommend assigning a new DOI and linking the new DOI to the previous DOI with related identifiers.


  4. Sep 2023
  5. Jul 2023
  6. Apr 2023
  7. Mar 2023
    1. Unable to see a previous version of your file? The revisions for your file may occasionally be merged to save storage space. Note: If you don't have permission to edit a file, you won't be able to see the version history.

      In other words, Google Docs can't be relied on for versioning.

  8. Jan 2023
  9. Dec 2022
  10. Oct 2022
    1. If the common storage type has to be changed (for example from string to int), a migration of content is perfomed together with any necessary update of the mapping code
    1. With a well-defined versioning strategy, when releasing a non-backwards compatible version, you can keep the existing one and the new one working in parallel for a pre-defined window of time
    1. you will need to accommodate backwards compatibility or support multiple versions of an API running in parallel
  11. Aug 2022
  12. Apr 2022
  13. Mar 2022
  14. Jan 2022
    1. The key thing about the REST approach is that the server addresses the client state transitions. The state of the client is almost totally driven by the server and, for this reason, discussions on API versioning make little sense, too. All that a client should know about a RESTful interface should be the entry point. The rest should come from the interpretation of server responses.
  15. Sep 2021
    1. My understanding is that the caret is the answer for traditional SemVer, i.e., there will be breaking changes prior to 0.1.0, there may be breaking changes between minor versions prior to 1.0.0, and there may only be breaking changes between major versions above 1.0.0.
  16. Aug 2021
    1. The TypeScript team has made it clear. They do not follow semver. "minor" (X.X) releases can contain breaking changes. Major releases (X) have very little meaning.
  17. Dec 2020
  18. Nov 2020
    1. Adapters are strictly versioned: any change to an adapter interface - associative or not - is considered breaking and will cause a major version update of the component.
    1. I feel that with all that power that it’s gaining, instead of being a more approachable tool, that it’s actually being a tool that is continuously making people feel frustrated, to the point where I feel that whatever the next version control system is… (And it does not have to be something separate than Git. It should maybe be just a really powerful abstraction built on top of Git.) But I think whatever the next iteration of the people’s version control is… it should be something that is more reflective of how we think about what version control is for us.
  19. Oct 2020
  20. Sep 2020
    1. The versions must be compatible, so if a peerDependency is listed as 2.x, you can’t install 1.x or another version. It all follows semantic versioning.
  21. Apr 2020
  22. Jan 2020
  23. Nov 2018
  24. Jun 2018
    1. Barbary K. 2014 sncosmo Zenodo, 10.5281/zenodo.11938

      This software citation losts its version information. We will have to work on our typsetting and production rules, as well as develop formal JATS/NLM XML schema to contain versioning information.

  25. Oct 2017
  26. May 2015
    1. I'm a big fan of the approach that Stripe has taken to API versioning -

      Ouch ! :/ I read somewhere else that this was in fact very bad practice...