search

sbt / sbt-ghpages

git, site and ghpages support for sbt projects.
Other
91 stars 20 forks source link

Support for maintaining old/multiple versions of site/documents by enabling ghpagesKeepVersions flag. #39

Open kpritam opened 6 years ago

kpritam commented 6 years ago

Fixes #10

lightbend-cla-validator commented 6 years ago

Hi @kpritam,

Thank you for your contribution! We really value the time you've taken to put this together.

Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:

http://www.lightbend.com/contribute/cla

kpritam commented 6 years ago

Signed Lightbend CLA

kpritam commented 6 years ago

Is there any other better way to maintain versioning in ghpages published docs?

julienrf commented 4 years ago

@kpritam This contribution looks great! Do you mind adding a test for it? (in the sbt-test directory)

kpritam commented 4 years ago

@kpritam This contribution looks great! Do you mind adding a test for it? (in the sbt-test directory)

I have added test, do have a look and let me know if thats fine.

julienrf commented 4 years ago

Another question is coming to my mind. I am still not sure whether maintaining multiple versions should be done at the sbt-site level or sbt-ghpages level… With your proposal, would it be possible and easy to publish a website for v1.0 of a lib, then publish for v2.0, and then for v1.1 but while still having the website for 2.0 by default?

kpritam commented 4 years ago

With your proposal, would it be possible and easy to publish a website for v1.0 of a lib, then publish for v2.0, and then for v1.1 but while still having the website for 2.0 by default?

As per the current proposal, last published version is copied to root directory as it does not know about previously published versions. Simplest way to achieve what you described could be setting ghpagesCopyLatestVersionAtRoot := false while releasing v1.1 (consumer of ghpages responsibility) Or We could somehow keep track of published version and then sort and decide what goes at top level Or We could peek into current gh-pages repo to see what versions are published.

Another question is coming to my mind. I am still not sure whether maintaining multiple versions should be done at the sbt-site level or sbt-ghpages level…

ghpages plugin cleans repository at the time of every publish, hence this needs to be done in ghpages plugin.

julienrf commented 4 years ago

ghpages plugin cleans repository at the time of every publish, hence this needs to be done in ghpages plugin.

Alternatively, we could create a new folder for old versions each time we start a new major branch.

kpritam commented 4 years ago

ghpages plugin cleans repository at the time of every publish, hence this needs to be done in ghpages plugin.

Alternatively, we could create a new folder for old versions each time we start a new major branch.

This will force keeping older versions. What if people do not want older versions like the way ghpages currently behaves?