Ship Log

Changelog archive

Every version of Ship Log from 2.9 back to 0.1, newest first, moved here word for word.

The recent entries are on the changelog page.

Version 2.9

Not yet checked in a real browser.

Step 2's copy now names the third case the word count can land you in. It said the count names the longest lines to move once an entry passes 150 words, but it did not say what happens when the item lines cannot fix it on their own — an entry with no item lines at all, or too few short ones to take out enough words. The hint itself has said this honestly since 2.7; the page around it did not.
It now says that when the item lines alone cannot bring the entry back under the limit, the hint says so instead of naming a move that would still leave it too long, and gives the word count of the known-problems line — the one part that cannot be moved into an older entry — so that is the line to shorten, or the release to split into two versions.
Only the copy in index.html changed. Nothing about how the tool writes: the entry, the tags, tick state, the rendered preview, the word count, the lines-to-move hint, the hype check and the copy buttons all behave as they did in 2.8.

Known problems: not yet checked in a real browser; the branch of the hint that this copy describes threw an error instead of printing its sentence, because the function behind it shadowed a helper with one of its own argument names, so the promise in this copy was not true until 2.14; the example that "Fill with an example" fills in still described the version 2.7 release, and its "next up" line pointed at the copy work this release just did, so the example was a release behind again (fixed in 2.10); the lines-to-move hint calls the longest lines the ones to move, which is a fair guess but not always the right one — the line that belongs in an older version is the one you know is older, not necessarily the longest (fixed in 2.16); the rendered preview's colours and spacing come from this page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut "was:" hint is only shown by pointing at the hint, which a touch screen does not do (2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.8

Not yet checked in a real browser.

"Fill with an example" now fills in the version 2.7 entry of this tool, with the 2.6 entry pasted into step 4 below it. The example had been left sitting at 2.5, so it was two releases behind: it showed neither the lines-to-move hint added in 2.6 nor the fix to that hint in 2.7, and pressing the button showed a picture of an older tool.
The example's three lines now describe the 2.7 work — the hint that only counted item lines and could name a move that still left the entry over the limit, the weight it now adds up before it speaks, and the honest sentence for a long entry with no item lines in it at all — so the example and the page agree.
Its known-problems line is honest about what is still untested and still a guess, and its "next up" line points at the copy work planned for the next release: saying in step 2 when a long entry is over the limit because of its known-problems line.
Only example.js changed. The texts, the tags, the tick state, the preview, the word count, the lines-to-move hint, the hype check and the copy buttons behave exactly as they did in 2.7.

Known problems: not yet checked in a real browser; the example is written by hand, so it describes the last release of this tool and not your own version, and it has to be refreshed with each release — it is one small file now, but it is not generated from this changelog (fixed in 2.21); the lines-to-move hint calls the longest lines the ones to move, which is a fair guess but not always the right one — the line that belongs in an older version is the one you know is older, not necessarily the longest (fixed in 2.16); the rendered preview's colours and spacing come from this page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut "was:" hint is only shown by pointing at the hint, which a touch screen does not do (2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again; the copy in step 2 still said the count only ever names lines to move, and did not name the known-problems case (fixed in 2.9).

Version 2.7

Not yet checked in a real browser.

Fixed the "which lines to move" hint under the word count in step 2. It only ever counted the item lines and then promised a weight, so an entry kept over 150 words by a long known-problems line got advice that could not fix it: moving the item lines it named would still leave the entry over the limit, while the hint said the move "would bring this entry to about N words", which could still be above 150.
It now adds up every item line first. When moving all of them would still leave the entry over the limit, it says plainly that the item lines cannot fix this one on their own, gives the word count that would be left, and names how many words the known-problems line holds, which is the part that stays put. It then suggests shortening that line or splitting the release into two versions.
An entry that is long with no item lines in it at all now gets the same honest sentence instead of no hint: it says the entry has no item lines in it and points at the known-problems line.
The three existing phrasings are unchanged for the ordinary case (one line is enough, all the named lines are enough, three named lines are not enough), and the hint still only names lines; it moves nothing itself.
Nothing else changed: the texts, the tags, the tick state, the rendered preview, the word count, the hype check and the copy buttons behave as they did in 2.6.

Known problems: not yet checked in a real browser; the sentence this release added in the item-lines-cannot-fix-it case threw an error instead of printing, because the function behind it named one of its own arguments after a helper of the same name in the same file (fixed in 2.14); the hint calls the longest lines the ones to move, which is a fair guess but not always the right one — the line that belongs in an older version is the one you know is older, not necessarily the longest; the example is still written by hand, so it still has to be refreshed with each release — it held the 2.5 entry, two releases behind (fixed in 2.8); the rendered preview's colours and spacing come from this page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut "was:" hint is only shown by pointing at the hint, which a touch screen does not do (2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.6

Not yet checked in a real browser.

Step 2 now names the lines to move when an entry is long. Before this it only said the entry was past 150 words and suggested moving "the older lines", which left you to work out which ones. Now, under the count, it lists the longest item lines — up to three, each cut short with its word count — and says how many of them it would take to get back under 150 words, and roughly what the entry would then weigh.
The arithmetic is done on the finished entry the rest of the tool has already written, and the words of the items named are subtracted from that whole entry, so the figure says what moving those lines out of step 1 would actually do. It only names lines; it moves nothing itself.
The hint disappears the moment the entry is short again, and it says so plainly when three lines are not enough on their own, so a very long entry is not left looking solved.
Nothing else changed: the texts, the tags, the tick state, the preview, the count, the hype check and the copy buttons behave as they did in 2.5.

Known problems: not yet checked in a real browser; the hint calls the longest lines the ones to move, which is a fair guess but not always the right one — the line that belongs in an older version is the one you know is older, not necessarily the longest; it counts the item lines only, so an entry kept over 150 words by a very long known-problems line could not be fixed by what it suggested, and it could even name a move that left the entry still over the limit (fixed in 2.7); the example is still written by hand, so it still has to be refreshed with each release; the rendered preview's colours and spacing come from this page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut "was:" hint is only shown by pointing at the hint, which a touch screen does not do (2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.5

Not yet checked in a real browser.

Moved the example text that "Fill with an example" puts on the page into its own small file, example.js, loaded just before app.js. The example is the part of the page that has to change with every release, and it used to sit inside the largest file, so refreshing it meant rewriting that whole file. Now it is one short file of plain data.
Refreshed the example to the version 2.4 entry of this tool, so it is back in step with the release: the three lines describe the word count under the changelog entry, the known-problems line is honest about what is untested, and the 2.3 entry is pasted into step 4 as the older entry.
If example.js is missing or fails to load, the button still works: it fills an empty form and says on the status line that the example file did not load, instead of doing nothing or half-filling the page.
Step 1 now says in one line what the example is: the last release of Ship Log itself, not your own version.
Nothing else changed: the texts, the tags, the tick state, the preview, the word count, the hype check and the copy buttons behave as they did in 2.4.

Known problems: not yet checked in a real browser; the example is still written by hand, so it still has to be refreshed with each release — it is one small file now, but it is not generated from the changelog; the rendered preview's colours and spacing come from this page, not from your own page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut "was:" hint is only shown by pointing at the hint, which a touch screen does not do (2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.4

Not yet checked in a real browser.

Added a count under the changelog entry in step 2: how many words and how many characters this version's entry holds, updated as you type. Before this you had to guess whether an entry had grown too long to scan in one sitting.
Past 150 words the count says so plainly and suggests either splitting the release into two versions or moving the older lines into the entries you paste in step 4. Below that it is just the count.
The count reads the finished entry straight from the text box next to it, so it always describes exactly the text you would paste, and it is drawn by preview.js — the same small file that draws the rendered preview in step 3 — so the rest of the tool is untouched by this change.
Nothing else changed: the texts, the tags, the tick state, the preview, the hype check and the copy buttons behave as they did in 2.3.

Known problems: not yet checked in a real browser; "Fill with an example" still filled in the version 2.2 entry, so the example was two releases behind (fixed in 2.5, where it also moved into its own file); the rendered preview's colours and spacing come from this page, not from your own page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut "was:" hint is only shown by pointing at the hint, which a touch screen does not do (2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.3

Not yet checked in a real browser.

The "was:" hint under a reworded row now cuts the old line at 40 characters instead of 64, at a word where it can, so the hint stays on one line on a phone instead of wrapping onto three. The hint is there to show which old line a row was matched to, not to print it in full, and a cut hint always ends in an ellipsis so it never looks like the whole line.
The full old line is still reachable: the hint carries it as its title text, so pointing at the hint shows the whole line. It is the line that sat there before you reworded it, and it is still in step 1 above.
"Fill with an example" now fills in the version 2.2 entry for this tool, with the 2.1 entry pasted below it, so the example is back in step with the release instead of a version behind.
Nothing else changed: the tags, the tick state, the preview, the hype check, the texts and the copy buttons behave as they did in 2.2.

Known problems: not yet checked in a real browser; the rendered preview's colours and spacing come from this page, not from your own page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the full old line behind a cut hint is only shown by pointing at the hint, which a touch screen does not do; the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.2

Not yet checked in a real browser.

Every read-only output box now carries a label naming what it holds, so a screen reader announces "Changelog entry", "Public update" or "Note to your future self" when focus lands in the box, instead of leaving the reader to work it out from the placeholder text alone. This covers the five texts in steps 2 to 6 and the one-block box in step 8.
The rendered preview in step 3 is now a labelled region, and the hype check list in step 7 carries a label too, so both are announced as named parts of the page rather than as loose paragraphs.
The label on the public update box says it is read only until you press "Edit by hand", which is the state the box actually starts in.
Nothing else changed: the texts, the tags, the tick state, the preview, the hype check and the copy buttons all behave as they did in 2.1.

Known problems: not yet checked in a real browser; the rendered preview's colours and spacing come from this page, not from your own page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the "was:" hint under a reworded row cut the old line at 64 characters, which is more than a one-line hint needs (shortened to 40 in 2.3); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.1

Not yet checked in a real browser.

Fixed "Fill with an example": it was still filling in the version 1.9 entry, so the example did not show the rendered preview added in 2.0, and the version it wrote into step 1 was a release out of date. It now fills in a version 2.0 entry whose three lines are the preview work.
The example's known-problems line and its "next up" line now match what is true today, and the older entry it pastes into step 4 is the 1.9 entry. The example is meant to be a working picture of the tool, so it will be kept in step with each release from now on.
Nothing else changed in how the tool writes: the texts, the tags, the tick state and the preview all behave as they did in 2.0.

Known problems: not yet checked in a real browser; the rendered preview's colours and spacing come from this page, not from your own page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 2.0

Not yet checked in a real browser.

Step 3 now shows a rendered preview of this version's entry under the HTML snippet: the same heading, the same list and the same known-problems line, laid out the way a reader of a changelog page would see it. Before this you had to paste the snippet somewhere to know how it read.
The preview redraws as you type in step 1, and it follows an item you move or a line you tick, because it reads the fields straight from the page rather than being handed a copy.
It is built one node at a time with createElement and textContent, so nothing you type is ever turned into markup in the preview. It is styled with this page's own stylesheet, so the look is close to, not identical to, your own changelog page.
The preview lives in its own small file, preview.js, so the rest of the tool is untouched by this change.

Known problems: not yet checked in a real browser; the preview's colours and spacing come from this page, not from your own page; a line rewritten in completely new words still reads as "new" and starts ticked (1.9); "Fill with an example" still filled in the 1.9 wording, so the example did not show the preview (fixed in 2.1); the public update still names at most the first three ticked items and counts the rest; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.9

Not yet checked in a real browser.

Tightened the loose line reading in step 1, which is the one that pairs a reworded line with the older line sitting in the same slot. It now needs real evidence: two shared words of five letters or more, or one shared word of eight letters or more, or letter runs that still line up. Before this, any single shared word of four letters or more was enough.
Generic change verbs (added, fixed, changed, moved, removed, updated, rewrote and the like) no longer count as evidence at all, since almost every changelog line contains one. That is the case where two unrelated lines sitting in the same slot were paired with each other: they happened to share one short, generic word.
The tighter rule is used by the "new" / "edited" tag, by the "was:" hint under a row and by the tick state, so it all stays consistent. Step 1 now says what the loose reading catches and what it still misses.
Trade-off, stated plainly: a rewrite that keeps only one middling shared word, with no letter runs in common, now reads as "new" and starts ticked. Check the list before you ship.

Known problems: not yet checked in a real browser; a line rewritten in completely new words still reads as "new" and starts ticked; the stricter rule also means a rewrite that keeps only one middling word reads as "new" and starts ticked; the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.8

Not yet checked in a real browser.

Loosened the line comparison in step 1, so a line you rewrite in the same place in the list is tagged "edited" instead of "new". The strict check runs first across the whole list, as before: the opening words match, or the two lines share two long words. Only when nothing matches is the one older line sitting in the same slot read loosely — one long word still in common (in lines that each have a few), or letter runs that still line up — and that counts as the same line in new words.
The looser reading is used by the "edited" tag, by the "was:" hint under the row and by the tick state, so a reworded line also keeps the tick you gave it and "Tick the tagged lines" still puts it into the public update.
Step 1 says plainly what the loose reading catches and what it still misses. A line rewritten in completely new words, with nothing of the old wording left, still reads as "new".

Known problems: not yet checked in a real browser; the loose reading could pair two unrelated lines that happened to sit in the same slot and share one short word (it never ran across the whole list, which kept that rare; tightened in 1.9); a line rewritten in completely new words still reads as "new"; the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.7

Not yet checked in a real browser.

Added a "Tick the tagged lines" button under the item list in step 1. One press ticks exactly the lines tagged new or edited since your last marking point and leaves every other line out of the short public update, so at ship time the update names what this version changed instead of every line still sitting in step 1. The changelog entry is unchanged and still keeps all of them.
The tags themselves are left alone by that button, so you can check them against your ticks before clearing them with Mark as read. If nothing is tagged, the button ticks nothing and says so instead of silently emptying the update.
Step 1 now names the four buttons and what each one does.

Known problems: not yet checked in a real browser; the word comparison needs two long words in common, so a line rewritten into completely different wording read as "new" (made less likely in 1.8); the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.6

Not yet checked in a real browser.

Under any row tagged "edited", step 1 now shows the old line that row was matched to ("was: ..."), so you can check the match instead of trusting it. The hint is cut at a word if the old line is long, and it disappears as soon as the row is no longer tagged.
When more than one old line reads like the row, the closest match is the one shown: opening words that still match count first, then the number of long words the two lines share.
"Mark as read" clears those hints along with the tags and still leaves your ticks alone.

Known problems: not yet checked in a real browser; the word comparison needs two long words in common, so a line rewritten into completely different wording still reads as "new", starts ticked and shows no hint; the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.5

Not yet checked in a real browser.

Added a "Mark as read" button under the item list in step 1. It clears the new and edited tags on every row and leaves the ticks you set exactly as they are, so you can finish reading the list without changing what goes into the public update. Before this, the only way to clear the tags was Tick all or Untick all, which also changed the ticks.
The tags are redrawn in place by that button, so the rows are not rebuilt and nothing else on the row moves.
Step 1 now says plainly what each of the three buttons does: Mark as read clears the tags only, Tick all and Untick all clear the tags and change the ticks.

Known problems: not yet checked in a real browser; the word comparison needs two long words in common, so a line rewritten into completely different wording still reads as "new" and starts ticked; the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.4

Not yet checked in a real browser.

Fixed the tick state in step 1 so a line keeps it when its wording changes. A reworded line is now matched to the old one by the long words the two lines share, not only by how they start, so unticking a line and then rewriting it past its opening words no longer puts it back into the public update. A line that is genuinely new still starts ticked, and a line that was deleted still cannot pass its tick to another line.
The tag on the right of a row uses the same word comparison, so a reworded line reads "edited" rather than "new".
Each tag now carries a label ("New since you last marked the list" or "Edited since you last marked the list") instead of being hidden from screen readers.

Known problems: not yet checked in a real browser; the word comparison needs two long words in common, so a line rewritten into completely different wording still reads as "new" and starts ticked; the only way to clear the tags was Tick all or Untick all, which also changed the ticks (fixed in 1.5); the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.3

Not yet checked in a real browser.

Added a tag on the right of each row in step 1: "new" for a line you typed after you last marked the list, "edited" for a line whose wording changed while it kept its place. A line that is unchanged carries no tag.
The marking points are the page loading, "Fill with an example", "Clear", "Tick all" and "Untick all", so one press of Tick all clears every tag once you have read the list. The line above the list also counts how many lines are tagged.
Moving a row with the arrows now carries its tag along with its tick state, and the item list is redrawn on a move so the tags cannot sit on the wrong line.

Known problems: not yet checked in a real browser; the tags compared wording by its opening only, so a line reworded beyond its first twelve characters read as "new" rather than "edited" (fixed in 1.4); the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state and the tags are held in memory only, so reloading the page starts again.

Version 1.2

Not yet checked in a real browser.

Fixed the tick boxes in step 1 so a line you edit the wording of keeps the tick state you gave it. If you unticked a line and then reworded it, it used to read as a brand new line and come back into the public update.
Step 8 (everything in one block) is now built by the same script as the rest of the page, at the end of every redraw, instead of by a second script that relied on the order the two files loaded in. Same output, one less file to load.

Known problems: not yet checked in a real browser; the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; the tick state is still held in memory only, so reloading the page starts again.

Version 1.1

Not yet checked in a real browser.

Fixed the tick boxes in step 1: deleting a line in the middle of the list can no longer hand its tick to another line that happens to read the same. The old list is now walked in order and each old line is claimed at most once, so a tick stays with the line it belongs to and a genuinely new line starts ticked.

Known problems: not yet checked in a real browser; the public update still names at most the first three ticked items and counts the rest; the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place; editing a line's wording re-ticked it, because a rewritten line read as a new one (fixed in 1.2).

Version 1.0

Not yet checked in a real browser.

Fixed the item list in step 1 so it is no longer rebuilt from scratch on every keystroke. While the number of items stays the same, each existing row is now refreshed in place, so a tick box, its label and any keyboard focus survive ordinary typing.
Added a hint in the hype check for long lists: past twelve items in step 1, it says the entry is hard to scan and suggests splitting the release into two versions or moving the older lines into the entries you paste in step 4.

Known problems: not yet checked in a real browser; the public update still names at most the first three ticked items and counts the rest; deleting an item in the middle of the list could hand its tick state to a line whose wording was close to it (fixed in 1.1); the rows are rebuilt (and focus restored) when items are added, deleted or moved, only typing is handled in place.

Version 0.9

Not yet checked in a real browser.

Fixed the tick boxes in step 1: they are now remembered by the item's position in the list rather than by its wording, so editing a line's text no longer silently puts an unticked item back into the public update.
Moving an item with the arrows carries its tick state along with it, so the tick follows the line rather than staying at the old position.
An item that is genuinely new always starts ticked, and its wording is matched against the items already there when the list shifts under it.

Known problems: not yet checked in a real browser; the item list in step 1 is still rebuilt whenever the text changes, so keyboard focus is only restored after a move, not after typing; the public update still names at most the first three ticked items and counts the rest; deleting an item in the middle of the list can hand its tick state to a line whose wording is close to it.

Version 0.8

Not yet checked in a real browser.

New step 8 puts all five texts in one block, each under its own label, with a single Copy all button. Use it when you want to paste the whole set into a file, a tracker or a commit message at once.
The block follows the public update as it is on screen, so if you edited that update by hand, your wording is what gets copied, not the generated text.
It is built from the finished texts on the page, so it cannot drift out of step with the steps above.

Known problems: not yet checked in a real browser; the item list in step 1 is rebuilt whenever the text changes, so keyboard focus is only restored after a move, not after typing; unticking was remembered by the item's wording, so rewording an item put it back in the public update; the public update still names at most the first three ticked items and counts the rest.

Version 0.7

Not yet checked in a real browser.

Fixed the public update so it never runs past 280 characters. The trim marker was being added after the cut, which pushed a long update over the limit; it is now counted inside it.
The hype check says plainly when the update had to be trimmed, and tells you to untick an item or shorten step 1 rather than leaving the missing words a mystery.
Added a warning when a hand-edited update is longer than 280 characters, with the character count, so you can shorten it before you post.

Known problems: not yet checked in a real browser; the item list is rebuilt whenever the text changes, so focus is only restored after a move, not after typing; the public update still names at most the first three ticked items and counts the rest.

Version 0.6

Not yet checked in a real browser.

New step 4 gives you the whole changelog page, not just one entry: a complete file with doctype, head, title, a link to style.css, this version's entry on top and your older entries under it, ready to save as changelog.html.
Paste the part of your existing changelog you already have and it is passed through unchanged. Leave it empty and the export carries a placeholder comment where older entries go.
The page title and heading are built from your project name, and the file links back to index.html from its footer.
The hype check gained two hints: it tells you when pasted older entries contain a script tag, or a style attribute that the exported page would ignore.

Version 0.5

Not yet checked in a real browser.

Step 5 now has a "First word" choice: Shipped, Released, Fixed, Changed, Added or Wrote. Pick one and the public update starts with that word; a line next to it says what each opener is for.
The opener only rewrites the generated text. If you are editing the update by hand, changing the opener leaves your wording alone.
"Fill with an example" and "Clear" put the opener back to Shipped.

Known problems: the item list is still rebuilt whenever the text changes, so focus is only restored after a move, not after typing; the update still names at most the first three ticked items and counts the rest.

Version 0.4

Not yet checked in a real browser.

The public update is yours to edit. "Edit by hand" in step 5 unlocks the text box; from then on the generator stops rewriting it, and the character counter keeps counting as you type.
"Back to auto text" locks the box again and puts the generated wording back. "Fill with an example" and "Clear" also go back to auto mode.
The hype check now says plainly when you are in hand-edit mode, and it checks your edited text instead of the generated one.

Version 0.3

Not yet checked in a real browser.

Fixed the move buttons in step 1: after an item moves, focus stays on the same button at its new position, so an item can be nudged up or down more than once without using the mouse.
When the button you pressed becomes disabled at the end of the list, focus moves to the other arrow in the same row instead of being lost.

Version 0.2

Not yet checked in a real browser.

Added tick boxes and move buttons in step 1, so you choose which items go into the short public update and in what order. The changelog entry still keeps every item.
Added "Tick all" and "Untick all", and a line telling you how many items are in the update.
Fixed the public update so text that is too long is cut at a word instead of mid-word.
Added two honest hints in the hype check: when no item is ticked, and when more items are ticked than the update will name.

Known problems: the item list is rebuilt as you type, so a move button lost focus after one click; the update still names at most the first three ticked items and counts the rest.

Version 0.1

First version: five text fields in (project, version, what changed, known problems, next up) and four texts out (changelog entry, changelog.html snippet, public update with a live 280-character counter, and a BUILT / NEXT / BUGS / PLAN note).
A hype check that flags filler words, exclamation marks, promise words and items over 140 characters.
Copy buttons for each text, a fill-with-example button and a clear button. No storage, no network, nothing saved between visits.

Known problems: the texts were written but not yet checked in a real browser, and the public update was always built from the first three items.

Back to the changelog · Back to the tool