Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Prepared ref-distro for next release

  1. … 10 more files in changeset.
Updated documentation for v3.9.0

  1. … 10 more files in changeset.
Prepared ref-distro for the next release

  1. … 10 more files in changeset.
Updated documentation for v3.8.0

  1. … 10 more files in changeset.
Prepared ref-distro for the next release

  1. … 10 more files in changeset.
Updated documentation for v3.7.0

  1. … 10 more files in changeset.
Prepared repository for next release

  1. … 10 more files in changeset.
Update documentation to v3.6 versions

To 3.6 versions of documentation, and 3.6 versions of build artifacts.

  1. … 10 more files in changeset.
Revert "Update documentation to v3.5 versions"

This reverts commit b1cd78dc02ea571e07fd120ca53560b829219020.

  1. … 9 more files in changeset.
Update documentation to v3.5 versions

To 3.5 versions of documentation, and 3.5 versions of build artifacts.

  1. … 9 more files in changeset.
3.4.1 release
3.4.1 release
Restored snapshots and docs

  1. … 10 more files in changeset.
Updated docs for 3.4.1 release

  1. … 9 more files in changeset.
Revert "Update documentation to v3.4 versions"

This reverts commit d1eb1a66f0e6a2da5d88d79306f4c194b7f71952.

  1. … 9 more files in changeset.
Update documentation to v3.4 versions

To 3.4 versions of documentation, and 3.4 versions of build artifacts.

  1. … 9 more files in changeset.
Since we don't have the previously saved builds anymore, I'm creating branches for past releases. I added a simple Jenkinsfile which has two main stages - build and ERD generation. The links in doc...

Since we don't have the previously saved builds anymore, I'm creating branches for past releases. I added a simple Jenkinsfile which has two main stages - build and ERD generation.
The links in docs now point to the last successful builds on release branches, so that we wouldn't have to update links if we decided to rebuild our API docs later on. Does this make sense?
I also wonder if it's alright to modify versions on readthedocs.com to use branches instead of tags, but then the label would change (from v3.3.0 to rel-3.3.0). Otherwise, we would have to modify tags in each repo. What do you think?

OLMIS-4963: Bring back lost ERD and static docs for past releases
OLMIS-4963: Bring back lost ERD and static docs for past releases
LGTM

LGTM

OLMIS-4840, fix UI doc links
OLMIS-4840, fix UI doc links
OLMIS-4840, fix broken service api and erd doc links

Caused by moving build jobs to newly named pipeline jobs.

  1. … 8 more files in changeset.
Revert "Release of OpenLMIS Ref Distro v3.3"

This reverts commit 0a963ec3dbe8c227e0827f0ad8c721dc28523366.

  1. … 12 more files in changeset.
Release of OpenLMIS Ref Distro v3.3

* Update releasing instructions

Update to remove entry about updating openlmis-config, since that repo is now legacy.

* Update component versions in ref-distro

For 3.3.0 release.

* Update documentation to specific versions

For 3.3 release.

* Update ERD and API doc links

Update to build numbers instead of last successful build. Remove live versions of ERD and APIs (since they are not versioned).

  1. … 12 more files in changeset.