diff --git a/admin/publish b/admin/publish --- a/admin/publish +++ b/admin/publish @@ -1,177 +1,177 @@ #!/usr/bin/env bash # # Author: Gerwin Klein, NICTA # # publishes archive entry + main web pages on isa-afp # # This script expects Isabelle version >= 2008-10-05 # (uses isabelle instead of isatool) ## settings source "$(dirname "$0")/common" AFP_VERSION=afp-$VERSION ISABELLE_VERSION="Isabelle${VERSION}" DEST=afpweb@isa-afp.org: FILES=frs.sourceforge.net:/home/frs/project/afp/afp-$ISABELLE_VERSION/ -SRC=ssh://hg@bitbucket.org/isa-afp/$AFP_VERSION +SRC=ssh://hg@foss.heptapod.net/isa-afp/$AFP_VERSION if [ -n "$SF_LOGIN" ]; then LN=$SF_LOGIN else LN=$LOGNAME fi FILES=$LN@$FILES EXPORT_PRE=afp HG=hg DATE=`date '+%Y-%m-%d'` TAR=tar ## functions function usage() { echo echo "Usage: $PRG [options] [|-]" echo echo " Checks out web site and archive entries and publishes them on the isa-afp.org web site" echo echo "Options:" echo " -r use specified Isabelle version" echo " -f do not ask before publishing" echo " -t use specified path to isabelle tool script" echo echo "Examples:" echo " $PRG -r 2009 Example-Submission" echo " $PRG -t /usr/proj/Isabelle2009/bin/isabelle Isabelle2009 Example-Submission" echo echo " $PRG Example-Submission" exit 1 } ## argument checking [ "$#" -lt "1" -o "$1" = "-?" ] && usage INTERACTIVE="yes" while getopts "ft:r:" OPT do case "$OPT" in r) VERSION="$OPTARG" ;; f) INTERACTIVE="no" ;; t) ISABELLE_TOOL="$OPTARG" ISABELLE_VERSION="$1" shift ;; esac done shift $(($OPTIND - 1)) set_isabelle_tool EXPORT=$EXPORT_PRE-$DATE ### WD="$(pwd)" cd "$DIR" ROOT="$(hg root)" || fail "could not obtain repo root" cd "$ROOT" || fail "could not cd to repo root" echo "Checking sync with $SRC" -$HG outgoing $SRC && fail "Push changes to bitbucket first." +$HG outgoing $SRC && fail "Push changes to Heptapod first." echo "Exporting from working copy $ROOT" HG_EXPORT=afp-export-$DATE rm -rf $HG_EXPORT $HG archive -I thys -I web -I etc -I tools $HG_EXPORT || fail "hg archive failed." cd $HG_EXPORT echo -n $DATE > web/release-date.txt mkdir $EXPORT mv thys etc tools $EXPORT/ if [ "$1" != "-" ]; then echo "Cleaning up browser_info directory" BROWSER_INFO=`$ISABELLE_TOOL getenv -b ISABELLE_BROWSER_INFO` || fail "could not find browser info" [ -e "$BROWSER_INFO" ] && rm -rf $BROWSER_INFO HTML_THYS=web/browser_info/$ISABELLE_VERSION TARS=web/release mkdir -p $HTML_THYS ln -s $ISABELLE_VERSION web/browser_info/current ln -s ../front.css web/entries/front.css mkdir -p $TARS echo "Tarring [$EXPORT]" $TAR -cf $EXPORT.tar $EXPORT gzip --best -f $EXPORT.tar ln -s $EXPORT.tar.gz $TARS/afp-current.tar.gz mv $EXPORT.tar.gz $TARS/ echo "Generating HTML for [$@]" $ISABELLE_TOOL afp_build -- -v -c $@ || fail "isabelle afp_build failed on [$@]" cd $EXPORT/thys for ENTRY in $@; do if [ -d $ENTRY ]; then echo "Tarring [$ENTRY]" $TAR -cf $EXPORT_PRE-$ENTRY-$DATE.tar $ENTRY gzip --best -f $EXPORT_PRE-$ENTRY-$DATE.tar mv $EXPORT_PRE-$ENTRY-$DATE.tar.gz ../../$TARS/ ln -s $EXPORT_PRE-$ENTRY-$DATE.tar.gz ../../$TARS/$EXPORT_PRE-$ENTRY-current.tar.gz echo "Finished [$ENTRY]" fi done cd ../.. echo "Copying generated HTML" for DIR in $BROWSER_INFO/*; do if [ -d $DIR ]; then cp -r $DIR $HTML_THYS fi done if [ "$INTERACTIVE" == "yes" ]; then echo "Web pages are prepared for publication under" echo "[`pwd`/web/]." echo "Please check content." read -n 1 -p "Type y if you want to publish. Any other key quits." RESPONSE else RESPONSE="y" fi else RESPONSE="y" fi if [ "$RESPONSE" == "y" ]; then # if [ "$TARS" != "" ]; then # echo # echo "Pushing $EXPORT to [$FILES]" # scp $TARS/$EXPORT.tar.gz $FILES # fi echo echo "Publishing to [$DEST]" chmod -R g-w web chmod -R a+r web find web -type d | xargs chmod a+x chmod 755 web rsync -rplvz --links --rsh=ssh web/ $DEST && echo "Finished." else echo echo "Aborted." exit 1; fi diff --git a/doc/editors/new-entry-checkin.md b/doc/editors/new-entry-checkin.md --- a/doc/editors/new-entry-checkin.md +++ b/doc/editors/new-entry-checkin.md @@ -1,95 +1,100 @@ New Submissions (editors only) ------------------------------ **Mercurial Setup** As editor you have at least two working copies of the repository: current release branch and development version. - Start by making a directory `~/afp` where the different branches will go. - To set up the release version, in that directory do (fill in 20XX) - hg clone ssh://hg@bitbucket.org/isa-afp/afp-20XX release + hg clone ssh://hg@foss.heptapod.net/isa-afp/afp-20XX release - for development - hg clone ssh://hg@bitbucket.org/isa-afp/afp-devel devel + hg clone ssh://hg@foss.heptapod.net/isa-afp/afp-devel devel You might need to set up ssh keys on Heptapod for this to work. This can -be done under "Manage account/SSH Keys". +be done under "[Settings/SSH Keys][keys]". New submissions, changes to the web site and to admin scripts go into -afp/release. Gerwin merges these into the development version within a -day or two. +afp/release. About once a week, one of the editors should merge afp-release +into afp-devel, ideally making sure after the merge that the entry works in +the devel version, although that sometimes may be too much and be left for +the authors to fix themselves. Maintenance and changes on existing submissions all occur in afp/devel and go properly public with the next Isabelle release (they are only available as (public) development tar.gz's) +[keys]: https://foss.heptapod.net/profile/keys + **New Submissions** Everything happens in the release branch `afp/release`. 1. unpack tar file and move new entry to `afp/release/thys` 2. make sure there is a `thys/entryname/ROOT` file and add `entryname` to `thys/ROOTS`. For the former see the template in `thys/Example-Submission/ROOT`. In particular the entry should be in chapter AFP, and group `(AFP)`, i.e. chapter AFP session foo (AFP) = bar + 3. to check, run in `afp/release/thys` ../admin/testall -c (be sure to have `ISABELLE_RELEASES` set to the path where Isabelle releases are kept, e.g. `/home/proj/isabelle/`) 4. check license headers: if the authors want the code released under LGPL instead of BSD, each file should mention "License: LGPL" in the - header. + header. We only accept the BSD 3-Clause and LPGPL version 2.1 licenses + as they are printed in `thys/LICENSE` and `thys/LICENSE.LGPL`. 5. `hg add` and `hg commit` the new submission 6. Enter data for author/abstract/index/etc in the file `metadata/metadata`. Make sure that your editor uses UTF-8 encoding for this file to preserve special characters. If the entry uses a new topic or category, add it to metadata/topics (make sure there is an empty line at the end of the file). 7. Generate the new web site by running `../admin/sitegen` . 8. Use `hg st` and `hg diff` to make sure the generated html makes sense. The diff should be small and concern the new entry only. 9. `hg add` and `hg commit` the web site updates. 10. finally, when you are happy with everything, `hg push` all changes - to bitbucket. The publish script will refuse to publish if the + to Heptapod. The publish script will refuse to publish if the changes aren't pushed. 11. to publish the changes to the web, run ../admin/publish This will check out the Isabelle202X (=release) version of the - archive from bitbucket, will run the session `name` to generate + archive from Heptapod, will run the session `name` to generate HTML, produce a `.tar.gz` for the archive and for the entry, and will update the web pages on the server. The script will ask before it copies, so you can check locally if everything is as you want it. 12. That's it. Changes should show up at **New submission in devel** Although it is a condition of submission that the entry works with the current stable Isabelle version, occasionally it happens that a submission does not work with the stable version and cannot be backported, but is important/good enough to include anyway. In this case, we can't release the submission on the main web site yet, but we can add it to the development version of the archive, such that it is at least available to those who are working with the current Isabelle development snapshot. The check-in procedure is the same as for a normal release entry, apart from the fact that everything happens in the devel instead of release directory and that the last step (publish) is omitted. The authors of the entry should be notified that the entry will only show up on the front page when the next Isabelle version is released. diff --git a/doc/maintenance.md b/doc/maintenance.md --- a/doc/maintenance.md +++ b/doc/maintenance.md @@ -1,84 +1,86 @@ Maintaining an Entry in the AFP ------------------------------- To maintain an entry, you must have write access to the mercurial repository of the archive at [Heptapod][hetpa]. To get access, [sign up at Heptapod][hepta], and ask one of the [editors][editors] to add you to the AFP project. [hepta]: https://foss.heptapod.net [editors]: http://isa-afp.org/about.html#editors **Setup:** Check out the archive from the mercurial repository with: - hg clone ssh://hg@bitbucket.org/isa-afp/afp-devel + hg clone ssh://hg@foss.heptapod.net/isa-afp/afp-devel The command above will create a directory `afp-devel` where theories and additional files are located. You can register an ssh key for your -account at Bitbucket under "Manage Account/SSH keys" from the avatar -icon on the top right of the Bitbucket interface. +account at Heptapod under "[Settings/SSH keys][keys]" from the avatar +icon on the top right of the Heptapod interface. + +[keys]: https://foss.heptapod.net/profile/keys **Maintenance:** - Maintaining an entry means making sure that this entry works with the -current Isabelle development version. Maintainers are not supposed to -check in and push new entries. New entries must be reviewed and formally -accepted. They are created on the release branch by the editors. +Maintaining an entry means making sure that this entry works with the current +Isabelle development version. Maintainers are not supposed to check in and +push new entries. New entries must be reviewed and formally accepted. They +are created on the release branch by the editors. Depending on the type of the entry, you might want to work in close lock step with Isabelle development, i.e. fix the entry immediately each time it breaks, or loosely, i.e. only shortly before a new Isabelle release. The former is useful for libraries and base entries that are used by others, the latter is Ok for larger developments and leaf entries. Small changes might be done by the Isabelle development team for you as the change is introduced to Isabelle (don't be surprised when your entry changes slightly over time). You will be notified when an Isabelle release nears and your entry is broken. You can also choose to receive an automatic email notification each time your entry breaks (see below). **Technicalities:** - To get the current Isabelle development version, use hg clone http://isabelle.in.tum.de/repos/isabelle to clone the hg repository. See the README file inside for further instructions. - Set up your AFP repository as a component by adding `init_component "/path_to/afp-devel"` to your `~/.isabelle/etc/settings` (or use any other of the component adding mechanisms). You need this to get access to the AFP settings and the `afp_build` tool. - To check if entry `x` works, execute `isabelle afp_build x`. This assumes that the command `isabelle` would start up the current Isabelle development version. - To test all entries, run `isabelle afp_build -A`. (Running the script with `-?` will show options and usage information) - The changes you make to the mercurial repository will not show up on the AFP web pages immediately. This only happens when a new version of the archive is released (usually together with Isabelle). Please contact one of the editors if you feel there is something that should be made available immediately. The changes will show up with about 24h delay in the web development snapshot of the AFP. - If you make a change that is more than maintenance and that you think may be interesting to users of your entry, please add a manual change log in the file `afp-devel/metadata/metadata` by adding an `[extra-history]` section to your entry. If possible and sensible, this log should link to the relevant hg change set(s). See existing change logs like the one for JinjaThreads for examples. **Email Notification:** You can receive an automatic email notification if entry `x` breaks by editing the file `afp-devel/thys/x/config`: - To switch on: add your email address to `NOTIFY`, hg commit, and hg push the file. `NOTIFY` is a space separated list. If the entry is marked as `FREQUENT`, the test will run daily. - To switch off: remove your email address from `NOTIFY` and hg commit + push the file. diff --git a/metadata/templates/about.tpl b/metadata/templates/about.tpl --- a/metadata/templates/about.tpl +++ b/metadata/templates/about.tpl @@ -1,76 +1,76 @@ {% extends "base.tpl" %} {% block headline %} Archive of Formal Proofs {% endblock %} {% block content %}

About

The Archive of Formal Proofs is a collection of proof libraries, examples, and larger scientific developments, mechanically checked in the theorem prover Isabelle. It is organized in the way of a scientific journal. Submissions are refereed.

-

The archive repository is hosted on Bitbucket to +

The archive repository is hosted on Heptapod to provide easy free access to archive entries. The entries are tested and maintained continuously against the current stable release of Isabelle. Older versions of archive entries will remain available.

Editors

The editors of the archive are

Why

We aim to strengthen the community and to foster the development of formal proofs.

We hope that the archive will provide

  • a resource of knowledge, examples, and libraries for users,
  • a large and relevant test bed of theories for Isabelle developers, and
  • a central, citable place for authors to publish their theories

We encourage authors of publications that contain Isabelle developments to make their theories available in the Archive of Formal Proofs and to refer to the archive entry in their publication. It makes it easier for referees to check the validity of theorems (all entries in the archive are mechanically checked), it makes it easier for readers of the publication to understand details of your development, and it makes it easier to use and build on your work.

License

-

All entries in the Archive of Formal Proofs are licensed under +

All entries in the Archive of Formal Proofs are licensed under a BSD-style License or the GNU LGPL. This means they are free to download, free to use, free to change, and free to redistribute with minimal restrictions.

The authors retain their full copyright on their original work, -including their right to make the development available under another, +including their right to make the development available under another, additional license in the future.

{% endblock %} diff --git a/metadata/templates/status.tpl b/metadata/templates/status.tpl --- a/metadata/templates/status.tpl +++ b/metadata/templates/status.tpl @@ -1,62 +1,62 @@ {% extends "base.tpl" %} {% block headline %} Archive of Formal Proofs {% endblock %} {% block content %}

Test status of entries in the AFP development version

Isabelle revision: {{ build_data.isabelle_id }}
AFP revision: - + {{ build_data.afp_id }}
Build time:{{ build_data.time }}
Build URL:Jenkins
Job name:{{ build_data.job }}

 

{% for entry in entries %} {% endfor %}
[{{entry.status}}] {{entry.name}}
{% endblock %} diff --git a/metadata/templates/submitting.tpl b/metadata/templates/submitting.tpl --- a/metadata/templates/submitting.tpl +++ b/metadata/templates/submitting.tpl @@ -1,87 +1,87 @@ {% extends "base.tpl" %} {% block headline %} Submission Guidelines {% endblock %} {% block content %}

Please send your submission via this web page.

The submission must follow the following Isabelle style rules. For additional guidelines on Isabelle proofs, also see the this guide (feel free to follow all of these; only the below are mandatory). Technical details about the submission process and the format of the submission are explained on the submission site.

  • No use of the commands sorry or back.
  • Instantiations must not use Isabelle-generated names such as xa — use Isar, the subgoal command or rename_tac to avoid such names.
  • No use of the command smt_oracle.
  • If your theories contain calls to nitpick, quickcheck, or nunchaku those calls must include the expect parameter. Alternatively the expect parameter must be set globally via, e.g. nitpick_params.
  • apply scripts should be indented by subgoal as in the Isabelle distribution. If an apply command is applied to a state with n+1 subgoals, it must be indented by n spaces relative to the first apply in the sequence.
  • Only named lemmas should carry attributes such as [simp].
  • We prefer structured Isar proofs over apply style, but do not mandate them.
  • If there are proof steps that take significant time, i.e. longer than roughly 1 min, please add a short comment to that step, so maintainers will know what to expect.
  • The entry must contain a ROOT file with one session that has the name of the entry. We strongly encourage precisely one session per entry, but exceptions can be made. All sessions must be in group (AFP), and all theory files of the submission must be contained in - at least one session. See also the example ROOT file + at least one session. See also the example ROOT file in the Example submission.
  • The entry should cite all sources that the theories are based on, for example textbooks or research articles containing informal versions of the proofs.

Your submission must contain an abstract to be displayed on the web site – usually this will be the same as the abstract of your proof document in the root.tex file. You can use LaTeX formulae in this web site abstract, either inline formulae in the form $a+b$ or \(a+b\) or display formulae in the form $$a + b$$ or \[a + b\]. Other occurrences of these characters must be escaped (e.g. \$ or \\(). Note that LaTeX in the title of an entry is not allowed. Most basic LaTeX functionality should be supported. For details on what parts of LaTeX are supported, see the MathJax documentation.

It is possible and encouraged to build on other archive entries in your submission. There is a standardised way to refer to other AFP entries in your theories.

Your submission will be refereed and you will receive notification as soon as possible. If accepted, you must agree to maintain your archive entry or nominate someone else to maintain it. The Isabelle development team will assist with maintenance, but it does not have the resources to fully maintain the complete archive.

If you have questions regarding your submission, please email afp-submit@in.tum.de. If you need help with Isabelle, please use the isabelle-users@cl.cam.ac.uk mailing list. It is always a good idea to subscribe.

{% endblock %} diff --git a/metadata/templates/updating.tpl b/metadata/templates/updating.tpl --- a/metadata/templates/updating.tpl +++ b/metadata/templates/updating.tpl @@ -1,102 +1,102 @@ {% extends "base.tpl" %} {% block headline %} Updating Entries {% endblock %} {% block content %}

Change

The Archive of Formal Proofs is an online resource and therefore more dynamic than a normal scientific journal. Existing entries can and do evolve and can also be updated significantly by their authors.

This conflicts with the purpose of archiving and preserving -entries as they have been submitted and with the purpose of +entries as they have been submitted and with the purpose of providing a clear and simple interface to readers.

The AFP deals with this by synchronizing such updates with Isabelle releases:

  • The entries released and visible on the main site are always working with the most recent stable Isabelle version and do not change.
  • In the background, the archive maintainers evolve all entries to be up to date with the current Isabelle development version. Authors can contribute changes to this version which is available as a bitbucket +href="https://foss.heptapod.net/isa-afp/afp-devel/">Heptapod mercurial repository or as tar.gz package on the download page.
  • When a new Isabelle version is released, the above mentioned development version of AFP is frozen and turns into the main version displayed on the front page. Older versions (including the original submission) of all entries are archived and remain accessible.

Significant changes of an entry should be recorded in the metadata of the entry using the keyword "extra-history". The resulting web page should look something like this.

Monotonicity

Updating an entry should be mostly monotone: you add new material, but you do not modify existing material in a major way. Ideally, entries (by other people) that build on yours should not be affected. Otherwise you have to liaise with them first. If you intend to carry out major non-monotone changes, you will need to submit a completely new entry (with a description of how it relates to the old one). This should be required only very rarely: AFP entries should be mature enough not to require major changes to their interface (i.e. the main functions and theorems provided).

Major monotone changes, e.g. adding a new concept rather than more results on existing concepts, may also call for a new entry, but one that builds on the existing one. This depends on how you would like to organize your entries.

If you are an author

The above means that if you are an author and would like to provide a new, better version of your AFP entry, you can do so.

To achieve this, you should base your changes on the mercurial +href="https:/foss.heptapod.net/isa-afp/afp-devel/">mercurial development version of your AFP entry and test it against the current Isabelle development version.

-If you would like to get write access to your entry in the +If you would like to get write access to your entry in the mercurial repository or if you need assistance, please contact the editors.

{% endblock %} diff --git a/web/about.html b/web/about.html --- a/web/about.html +++ b/web/about.html @@ -1,144 +1,144 @@ Archive of Formal Proofs

 

 

 

 

 

 

Archive of Formal Proofs

 

About

The Archive of Formal Proofs is a collection of proof libraries, examples, and larger scientific developments, mechanically checked in the theorem prover Isabelle. It is organized in the way of a scientific journal. Submissions are refereed.

-

The archive repository is hosted on Bitbucket to +

The archive repository is hosted on Heptapod to provide easy free access to archive entries. The entries are tested and maintained continuously against the current stable release of Isabelle. Older versions of archive entries will remain available.

Editors

The editors of the archive are

Why

We aim to strengthen the community and to foster the development of formal proofs.

We hope that the archive will provide

  • a resource of knowledge, examples, and libraries for users,
  • a large and relevant test bed of theories for Isabelle developers, and
  • a central, citable place for authors to publish their theories

We encourage authors of publications that contain Isabelle developments to make their theories available in the Archive of Formal Proofs and to refer to the archive entry in their publication. It makes it easier for referees to check the validity of theorems (all entries in the archive are mechanically checked), it makes it easier for readers of the publication to understand details of your development, and it makes it easier to use and build on your work.

License

-

All entries in the Archive of Formal Proofs are licensed under +

All entries in the Archive of Formal Proofs are licensed under a BSD-style License or the GNU LGPL. This means they are free to download, free to use, free to change, and free to redistribute with minimal restrictions.

The authors retain their full copyright on their original work, -including their right to make the development available under another, +including their right to make the development available under another, additional license in the future.

\ No newline at end of file diff --git a/web/statistics.html b/web/statistics.html --- a/web/statistics.html +++ b/web/statistics.html @@ -1,307 +1,307 @@ Archive of Formal Proofs

 

 

 

 

 

 

Statistics

 

Statistics

- +
Number of Articles:545
Number of Authors:359
Number of lemmas:~147,800
Lines of Code:~2,571,700
Lines of Code:~2,571,600

Most used AFP articles:

NameUsed by ? articles
1. List-Index 15
2. Coinductive 12
Collections 12
Regular-Sets 12
3. Landau_Symbols 11
4. Show 10
5. Abstract-Rewriting 9
Automatic_Refinement 9
Deriving 9
Polynomial_Factorization 9
6. Jordan_Normal_Form 8
Native_Word 8

Growth in number of articles:

Growth in lines of code:

Growth in number of authors:

Size of articles:

\ No newline at end of file diff --git a/web/submitting.html b/web/submitting.html --- a/web/submitting.html +++ b/web/submitting.html @@ -1,155 +1,155 @@ Archive of Formal Proofs

 

 

 

 

 

 

Submission Guidelines

 

Please send your submission via this web page.

The submission must follow the following Isabelle style rules. For additional guidelines on Isabelle proofs, also see the this guide (feel free to follow all of these; only the below are mandatory). Technical details about the submission process and the format of the submission are explained on the submission site.

  • No use of the commands sorry or back.
  • Instantiations must not use Isabelle-generated names such as xa — use Isar, the subgoal command or rename_tac to avoid such names.
  • No use of the command smt_oracle.
  • If your theories contain calls to nitpick, quickcheck, or nunchaku those calls must include the expect parameter. Alternatively the expect parameter must be set globally via, e.g. nitpick_params.
  • apply scripts should be indented by subgoal as in the Isabelle distribution. If an apply command is applied to a state with n+1 subgoals, it must be indented by n spaces relative to the first apply in the sequence.
  • Only named lemmas should carry attributes such as [simp].
  • We prefer structured Isar proofs over apply style, but do not mandate them.
  • If there are proof steps that take significant time, i.e. longer than roughly 1 min, please add a short comment to that step, so maintainers will know what to expect.
  • The entry must contain a ROOT file with one session that has the name of the entry. We strongly encourage precisely one session per entry, but exceptions can be made. All sessions must be in group (AFP), and all theory files of the submission must be contained in - at least one session. See also the example ROOT file + at least one session. See also the example ROOT file in the Example submission.
  • The entry should cite all sources that the theories are based on, for example textbooks or research articles containing informal versions of the proofs.

Your submission must contain an abstract to be displayed on the web site – usually this will be the same as the abstract of your proof document in the root.tex file. You can use LaTeX formulae in this web site abstract, either inline formulae in the form $a+b$ or \(a+b\) or display formulae in the form $$a + b$$ or \[a + b\]. Other occurrences of these characters must be escaped (e.g. \$ or \\(). Note that LaTeX in the title of an entry is not allowed. Most basic LaTeX functionality should be supported. For details on what parts of LaTeX are supported, see the MathJax documentation.

It is possible and encouraged to build on other archive entries in your submission. There is a standardised way to refer to other AFP entries in your theories.

Your submission will be refereed and you will receive notification as soon as possible. If accepted, you must agree to maintain your archive entry or nominate someone else to maintain it. The Isabelle development team will assist with maintenance, but it does not have the resources to fully maintain the complete archive.

If you have questions regarding your submission, please email afp-submit@in.tum.de. If you need help with Isabelle, please use the isabelle-users@cl.cam.ac.uk mailing list. It is always a good idea to subscribe.

\ No newline at end of file diff --git a/web/updating.html b/web/updating.html --- a/web/updating.html +++ b/web/updating.html @@ -1,170 +1,170 @@ Archive of Formal Proofs

 

 

 

 

 

 

Updating Entries

 

Change

The Archive of Formal Proofs is an online resource and therefore more dynamic than a normal scientific journal. Existing entries can and do evolve and can also be updated significantly by their authors.

This conflicts with the purpose of archiving and preserving -entries as they have been submitted and with the purpose of +entries as they have been submitted and with the purpose of providing a clear and simple interface to readers.

The AFP deals with this by synchronizing such updates with Isabelle releases:

  • The entries released and visible on the main site are always working with the most recent stable Isabelle version and do not change.
  • In the background, the archive maintainers evolve all entries to be up to date with the current Isabelle development version. Authors can contribute changes to this version which is available as a bitbucket +href="https://foss.heptapod.net/isa-afp/afp-devel/">Heptapod mercurial repository or as tar.gz package on the download page.
  • When a new Isabelle version is released, the above mentioned development version of AFP is frozen and turns into the main version displayed on the front page. Older versions (including the original submission) of all entries are archived and remain accessible.

Significant changes of an entry should be recorded in the metadata of the entry using the keyword "extra-history". The resulting web page should look something like this.

Monotonicity

Updating an entry should be mostly monotone: you add new material, but you do not modify existing material in a major way. Ideally, entries (by other people) that build on yours should not be affected. Otherwise you have to liaise with them first. If you intend to carry out major non-monotone changes, you will need to submit a completely new entry (with a description of how it relates to the old one). This should be required only very rarely: AFP entries should be mature enough not to require major changes to their interface (i.e. the main functions and theorems provided).

Major monotone changes, e.g. adding a new concept rather than more results on existing concepts, may also call for a new entry, but one that builds on the existing one. This depends on how you would like to organize your entries.

If you are an author

The above means that if you are an author and would like to provide a new, better version of your AFP entry, you can do so.

To achieve this, you should base your changes on the mercurial +href="https:/foss.heptapod.net/isa-afp/afp-devel/">mercurial development version of your AFP entry and test it against the current Isabelle development version.

-If you would like to get write access to your entry in the +If you would like to get write access to your entry in the mercurial repository or if you need assistance, please contact the editors.

\ No newline at end of file