Dates for versions
32 views
Skip to first unread message
Oscar Levin
Nov 10, 2025, 12:05:45 PM (12 days ago) Nov 10
to PreTeXt development
I've been thinking about how to sell PreTeXt to instructors more. A really nice current feature is the versions that can allow Releasing Material over Time. You add a @component="week2" and then after week 2, add "week2" to the #version/@include in the publication file.
I say this, but I actually haven't used this feature since I'm always actually adding material day off, so my procrastination is all the version control I need. But I want to be better about this. Which brings me to my feature idea.
What if the value of @component was a yyyy-mm-dd date and #version/@include-prior="yes" was set (or some other new attribute to version). This would tell PreTeXt to add all components that had date prior to (or not after) the date on which you were compiling. If you combined this with a github action that rebuild every night at midnight, you would have an automatically updating course website.
I'm pretty sure I could hack such a feature together entirely in the CLI, by parsing all the components for dates, and adding components values to the @include prior to building with "standard" pretext. But it strikes me that xsl might be able to do this easier and maybe there would be an interest to add this feature to pretext proper.
Thoughts?
P.S. Some day there could be a script that updates all the dates automatically so you can use the same course materials from semester to semester!
Mitch Keller
Nov 10, 2025, 12:58:06 PM (12 days ago) Nov 10
to prete...@googlegroups.com
This is an intriguing idea, and I think worth implementing if the automated date updating was something that there was confidence would be rolled out before the next semester started.
--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c-cb191e01fd98n%40googlegroups.com.
Rob Beezer
Nov 11, 2025, 1:58:42 PM (11 days ago) Nov 11
to prete...@googlegroups.com
The email service I use has a feature where you can put a date string into a
specially constructed address, and then you *never* get email at that address
ever again after that date. So I'm totally sympathetic.
Versions is probably the biggest bang-for-the-buck chunk of code in all of
PreTeXt. Let's discuss markup here and make sure we keep this clean.
> if the automated date
> updating was something that there was confidence would be rolled out before the
> next semester started
There is always zero confidence about the roll out timing of any new feature.
Rob
On 11/10/25 09:57, Mitch Keller wrote:
> This is an intriguing idea, and I think worth implementing if the automated date
> updating was something that there was confidence would be rolled out before the
> next semester started.
>
>> On Nov 10, 2025, at 11:05 AM, Oscar Levin <oscar...@gmail.com> wrote:
>>
>> I've been thinking about how to sell PreTeXt to instructors more. A really
>> nice current feature is the versions that can allow Releasing Material over
>> Time <https://pretextbook.org/doc/guide/html/publisher-versions.html#version-
>> use-cases-6>. You add a @component="week2" and then after week 2, add "week2"
>> dev+uns...@googlegroups.com>.
>> groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c-
>> cb191e01fd98n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> dev+uns...@googlegroups.com>.
> msgid/pretext-dev/BC945BE4-E7DD-46E6-BBF9-CEFE7D693C46%40rellek.net?
> utm_medium=email&utm_source=footer>.
specially constructed address, and then you *never* get email at that address
ever again after that date. So I'm totally sympathetic.
Versions is probably the biggest bang-for-the-buck chunk of code in all of
PreTeXt. Let's discuss markup here and make sure we keep this clean.
> if the automated date
> updating was something that there was confidence would be rolled out before the
> next semester started
Rob
On 11/10/25 09:57, Mitch Keller wrote:
> This is an intriguing idea, and I think worth implementing if the automated date
> updating was something that there was confidence would be rolled out before the
> next semester started.
>
>> On Nov 10, 2025, at 11:05 AM, Oscar Levin <oscar...@gmail.com> wrote:
>>
>> I've been thinking about how to sell PreTeXt to instructors more. A really
>> nice current feature is the versions that can allow Releasing Material over
>> use-cases-6>. You add a @component="week2" and then after week 2, add "week2"
>> to the #version/@include in the publication file.
>>
>> I say this, but I actually haven't used this feature since I'm always actually
>> adding material day off, so my procrastination is all the version control I
>> need. But I want to be better about this. Which brings me to my feature idea.
>>
>> What if the value of @component was a yyyy-mm-dd date and #version/@include-
>> prior="yes" was set (or some other new attribute to version). This would tell
>> PreTeXt to add all components that had date prior to (or not after) the date
>> on which you were compiling. If you combined this with a github action that
>> rebuild every night at midnight, you would have an automatically updating
>> course website.
>>
>> I'm pretty sure I could hack such a feature together entirely in the CLI, by
>> parsing all the components for dates, and adding components values to the
>> @include prior to building with "standard" pretext. But it strikes me that
>> xsl might be able to do this easier and maybe there would be an interest to
>> add this feature to pretext proper.
>>
>> Thoughts?
>>
>> P.S. Some day there could be a script that updates all the dates automatically
>> so you can use the same course materials from semester to semester!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PreTeXt development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pretext-dev...@googlegroups.com <mailto:pretext-
>>
>> I say this, but I actually haven't used this feature since I'm always actually
>> adding material day off, so my procrastination is all the version control I
>> need. But I want to be better about this. Which brings me to my feature idea.
>>
>> What if the value of @component was a yyyy-mm-dd date and #version/@include-
>> prior="yes" was set (or some other new attribute to version). This would tell
>> PreTeXt to add all components that had date prior to (or not after) the date
>> on which you were compiling. If you combined this with a github action that
>> rebuild every night at midnight, you would have an automatically updating
>> course website.
>>
>> I'm pretty sure I could hack such a feature together entirely in the CLI, by
>> parsing all the components for dates, and adding components values to the
>> @include prior to building with "standard" pretext. But it strikes me that
>> xsl might be able to do this easier and maybe there would be an interest to
>> add this feature to pretext proper.
>>
>> Thoughts?
>>
>> P.S. Some day there could be a script that updates all the dates automatically
>> so you can use the same course materials from semester to semester!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PreTeXt development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> dev+uns...@googlegroups.com>.
>> To view this discussion visit https://groups.google.com/d/msgid/pretext-
>> dev/19ba824e-9f0b-4361-a98c-cb191e01fd98n%40googlegroups.com <https://
>> groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c-
>> cb191e01fd98n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> BC945BE4-E7DD-46E6-BBF9-CEFE7D693C46%40rellek.net <https://groups.google.com/d/
> msgid/pretext-dev/BC945BE4-E7DD-46E6-BBF9-CEFE7D693C46%40rellek.net?
> utm_medium=email&utm_source=footer>.
Oscar Levin
Nov 17, 2025, 9:38:17 AM (5 days ago) Nov 17
to PreTeXt development
Here is a further idea, mostly from the instructor viewpoint (although I am confident I could make it work on the dev side). This is largely inspired by the ideas of a "dynamic calendar".
What if elements have a @release attribute that is a formatted string such as "w3d2", indicating that the materials should be released after class on day 2 of week 3. This might be a Wednesday or Thursday, depending on your teaching schedule. The publication file contains a link to a schedule file that maps these to actual dates. That schedule file could be generated automatically through selection of start date and weekly teaching schedule. It could further be customized to account for breaks.
I think there are other reasons we might want to keep such a schedule file to support teaching materials. But I would also understand this being a bridge too far, at for now.
Andrew Scholer
Nov 17, 2025, 11:08:54 AM (5 days ago) Nov 17
to prete...@googlegroups.com
I think that is a bridge too far. Releasing content is an instructor concern. Markup for that does not belong in the text of the book. It would only work in the case of a book used only by the author. Even in that case, what if I have M/W and T/H that are slightly out of sync after a holiday? Or I teach a course in both a 2x2 and 4x1 format?
IMO release would be better handled in a book-serving platform (like Runestone) as an instructor level concern.
Andrew Scholer
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/98a76727-c233-46cf-aeca-4988e128fe62n%40googlegroups.com.
Oscar Levin
Nov 17, 2025, 11:23:07 AM (5 days ago) Nov 17
to prete...@googlegroups.com
Thanks Andrew. I hear all that, but don't want to forget the PreTeXt use-case of instructor-author for course materials. I agree that this is not really useful for a book, but as a course package, instructors already use versions to release material incrementally.
The point that this should be managed by an external system is well taken. So perhaps the correct approach is to leave pretext source as it is and use versions with an extra schedule file that the CLI or some external course management system uses to rebuild the book with specific versions based on the date. So this once again becomes a question of whether it is a pretext supported feature or a CLI-only feature that just uses the existing versions. I keep flip-flopping.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N8zomK1Rogw_Y97v1BUL_1EN6xNL%2BvSqjoGRdEGKiOj9g%40mail.gmail.com.
Rob Beezer
Nov 17, 2025, 12:40:53 PM (5 days ago) Nov 17
to prete...@googlegroups.com
An idea that needs a few details ironed-out first. So not fully-baked.
Leave version support syntax (@include, @component) and behavior exactly as is.
But, when a component is being considered for inclusion, go look at a mapping
from component-names to dates, living in the publisher file. If a
component-name is found there, react conditionally depending on the associated
date and today's date.
Useful for instructor materials. Maybe a bit distracting for a world-wide book.
We have had individuals who like to be author, publisher, instructor (I'm
looking in the mirror) who want to release parts of *their* book over the course
of a term (now I'm looking at Oscar). The above might be a mess, but might be
workable.
Brad does not one-off books on Runestone. In other words, DMOI shouldn't have
235 instances, all derived from the same source, but all different. But maybe
the above sheme could be adapted to limit visibility for a specific course,
based on a further mapping from component-names and dates to our unique HTML IDs
(on "subchapters")?
Rob
> versions.html#version- <https://pretextbook.org/doc/guide/html/
> publisher-versions.html#version->
> pretext- <https://groups.google.com/d/msgid/pretext->
> >> dev/19ba824e-9f0b-4361-a98c-cb191e01fd98n%40googlegroups.com
> <http://40googlegroups.com> <https://
> >> groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c-
> <http://groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c->
> >> cb191e01fd98n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> > http://www.rellek.net/ <http://www.rellek.net/>
> > BC945BE4-E7DD-46E6-BBF9-CEFE7D693C46%40rellek.net
> <http://40rellek.net> <https://groups.google.com/d/ <https://
> groups.google.com/d/>
> > msgid/pretext-dev/BC945BE4-E7DD-46E6-BBF9-
> CEFE7D693C46%40rellek.net <http://40rellek.net>?
> groups.google.com/d/msgid/pretext-dev/98a76727-c233-46cf-
> aeca-4988e128fe62n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N8zomK1Rogw_Y97v1BUL_1EN6xNL%2BvSqjoGRdEGKiOj9g%40mail.gmail.com?
> <https://groups.google.com/d/msgid/pretext-dev/CAOU9BaUEnGrd7S7%2B-eadY6%3DcKfs-
> myR%3DU9wYMPO-K0fWmMsORw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Leave version support syntax (@include, @component) and behavior exactly as is.
But, when a component is being considered for inclusion, go look at a mapping
from component-names to dates, living in the publisher file. If a
component-name is found there, react conditionally depending on the associated
date and today's date.
Useful for instructor materials. Maybe a bit distracting for a world-wide book.
We have had individuals who like to be author, publisher, instructor (I'm
looking in the mirror) who want to release parts of *their* book over the course
of a term (now I'm looking at Oscar). The above might be a mess, but might be
workable.
Brad does not one-off books on Runestone. In other words, DMOI shouldn't have
235 instances, all derived from the same source, but all different. But maybe
the above sheme could be adapted to limit visibility for a specific course,
based on a further mapping from component-names and dates to our unique HTML IDs
(on "subchapters")?
Rob
> publisher-versions.html#version->
> >> dev/19ba824e-9f0b-4361-a98c-cb191e01fd98n%40googlegroups.com
> <http://40googlegroups.com> <https://
> >> groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c-
> <http://groups.google.com/d/msgid/pretext-dev/19ba824e-9f0b-4361-a98c->
> >> cb191e01fd98n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> > http://www.rellek.net/ <http://www.rellek.net/>
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> > dev+uns...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> pretext-dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> > --
> > You received this message because you are subscribed to the
> Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> > dev+uns...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> > BC945BE4-E7DD-46E6-BBF9-CEFE7D693C46%40rellek.net
> <http://40rellek.net> <https://groups.google.com/d/ <https://
> groups.google.com/d/>
> > msgid/pretext-dev/BC945BE4-E7DD-46E6-BBF9-
> CEFE7D693C46%40rellek.net <http://40rellek.net>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send
>
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/98a76727-c233-46cf-aeca-4988e128fe62n%40googlegroups.com <https://
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-
> groups.google.com/d/msgid/pretext-dev/98a76727-c233-46cf-
> aeca-4988e128fe62n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N8zomK1Rogw_Y97v1BUL_1EN6xNL%2BvSqjoGRdEGKiOj9g%40mail.gmail.com
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N8zomK1Rogw_Y97v1BUL_1EN6xNL%2BvSqjoGRdEGKiOj9g%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CAOU9BaUEnGrd7S7%2B-eadY6%3DcKfs-myR%3DU9wYMPO-K0fWmMsORw%40mail.gmail.com
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> <https://groups.google.com/d/msgid/pretext-dev/CAOU9BaUEnGrd7S7%2B-eadY6%3DcKfs-
> myR%3DU9wYMPO-K0fWmMsORw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages