TiddlySpace alpha channel
PMario
During 2.6.3 beta testing time period, the alpha channel was not
updated anymore. It still is 2.6.3 (alpha 9) now
I tried to use "twrelease: beta" once. It activated stable 2.6.2
instead.
I'd suggest, that the "alpha" channel is allways updated. Even if the
numbering is "2.6.3 (beta 1-3)". If TS is updated with 2.6.3, there
should be a new "alpha 2.x.y" which excludes the deprecated
functions.
Since beta testing is over, "beta" channel should contain 2.6.3 stable
now until the next beta is active.
reasoning:
a) It should not be needed to change ServerSettings to get the newest
version.
b) alpha channel should not contain "depricated" functions. (see
deprecated posts).
c) beta testers should use stable now for some time, but should still
be beta testers.
What do you think?
-m
PMario
fits well.
Also the project "BrowserID", it is used for is quit interesting.
[1] http://lloyd.io/applying-gitflow
[2] https://browserid.org/users
chris...@gmail.com
> During 2.6.3 beta testing time period, the alpha channel was not
> updated anymore. It still is 2.6.3 (alpha 9) now
Yes, this is mostly because I was gone during the release process so
the actions to which I normally attend didn't get any attention:
* alpha releases for tiddlywiki
* packaging the new tiddlywiki in the tiddlywebwiki package
* packaging the latest alpha in tiddlyspace
I'm back now, so this stuff should get some attention in the new few
days.
It would be useful if the alpha handling was a bit more automated but
we're not quite there yet, and from my perspective any energy we were
to spend on improving the alpha release process for tiddlywiki is better
spent on the process for the other releases.
The intention is that the alpha release always be what's at HEAD from
within the last week or so.
--
Chris Dent http://burningchrome.com/
[...]
chris...@gmail.com
> The intention is that the alpha release always be what's at HEAD from
> within the last week or so.
5.1 (6534.50, r93220) and Chrome 13.0.782.112 so I'm unable to make an
alpha release.
They do pass in Firefox 3.5.7 and 6.0.
Martin Budden
Martin
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
>
>
PMario
> I'm back now, so this stuff should get some attention in the new few
> days.
> It would be useful if the alpha handling was a bit more automated but
ok. Since alpha channel worked quite well, since it was introduced, I
thought it is automated allready. So thx to chris-bot for the work
done :)
> ... and from my perspective any energy we were
> spent on the process for the other releases.
**Thinking about the latest release discussion in TW group [1].**
**Thinking about the persistent cookie discussions for the last
release ...**
Yes .. most energy should be focused to releases
But the way towards a release has to work too.
As Martin said at [1] the beta process doesn't work for file TWs. Or
better the community.
And I think one reason could be the following:
* All my file TWs contain valuable data.
* I don't want to use betas with valuable data.
* I don't even update them, without a reason.
* So if I decide to test a beta, I test it with a "test-beta" TW
** Since a "test-beta TW" doesn't contain valuable data it is rearly
used -> "not tested"
I think this is a reason, why the community starts testing with
releases and the reactions are quite harsh, if a release breaks
stuff.
-m
chris...@gmail.com
>> It would be useful if the alpha handling was a bit more automated but
>> we're not quite there yet, ...
> ok. Since alpha channel worked quite well, since it was introduced, I
> thought it is automated allready. So thx to chris-bot for the work
> done :)
chris-bot does a fair amount under cover of darkness...I should make
some clones.
> As Martin said at [1] the beta process doesn't work for file TWs. Or
> better the community.
> And I think one reason could be the following:
>
> * All my file TWs contain valuable data.
> * I don't want to use betas with valuable data.
> * I don't even update them, without a reason.
> * So if I decide to test a beta, I test it with a "test-beta" TW
> ** Since a "test-beta TW" doesn't contain valuable data it is rearly
> used -> "not tested"
>
> I think this is a reason, why the community starts testing with
> releases and the reactions are quite harsh, if a release breaks
> stuff.
That seems like a pretty good explanation of what's going on, but if
your analysis is correct, I don't see any easy solutions. I've got two
opinions though:
* Having broken-ness in releases is a normal part of the process. It
keeps dialog happening and dialog helps keep stuff happening.
Where that broken-ness causes angry reactions that suggests that the
features that break are poorly considered on various angles:
* They are too hard to test.
* Too complex to get right.
In those cases maybe they shouldn't exist?
* Personally, I think the self-update functionality is one of those
things that is too hard to test, too complex, and sets up bad
expectations. It should be removed and people should not do
self-update. Instead they should import their existing wikis into
new versions if they feel like it.
That's a _far_ safer way to manage one's data and just a better way
of managing one's information.
PMario
> That seems like a pretty good explanation of what's going on, but if
Me neither. For me it is a syncing problem and syncing isn't easy.
> ... I've got two
>
> * Having broken-ness in releases is a normal part of the process. It
> keeps dialog happening and dialog helps keep stuff happening.
allowed to handle my valuable data. If my "trusted system" get's a
flue, I am worried :)
> Where that broken-ness causes angry reactions that suggests that the
> features that break are poorly considered on various angles:
> * They are too hard to test.
> * Too complex to get right.
> In those cases maybe they shouldn't exist?
IMO most of the time it's problems with plugins and there
dependencies, added to the TW. I know, that the core team can't test
them. Some users even don't know, that it is a 3rd party plugin that
causes a problems, because they downloaded an existing TW, that has a
nice predefined feature set, that works for them. The file they are
using is TiddlyWiki. Even if it is a heavily adjusted one.
> * Personally, I think the self-update functionality is one of those
> things that is too hard to test, too complex, and sets up bad
> expectations. It should be removed and people should not do
Then the import function, needs to be heavily improved.
> ... Instead they should import their existing wikis into
> That's a _far_ safer way to manage one's data and just a better way
> of managing one's information.
one year, contains a lot of minor adjustments to eg: StyleSheets,
Plugins, Config tiddlers .... and it has a lot of dependencies.
If I try to import all of my modified tiddlers, into a vanilla TW, I
can't see, which are my modified tiddlers, and which are shadow or
core tiddlers.
To make a clean update, I shouldn't import the shadow or core
plugins. But I need to import modified shadow tiddlers. ...
Let's say I take the time to carefully select all the tiddlers I want
to import.
I click import ...
Let's say I accidentally forgot one or two important tiddlers.
The new TW will break. Worst case, the layout and edit mode breaks. So
delete the file and start over again. Or some plugins are missing
there config tiddlers. Finding the missing tiddler, with the import
dialog is close to impossible. (Having 200++ content tiddlers)
Some may think: "Most users don't have that many tweaked tiddlers".
That doesn't matter. According to Murphy's law it will be the _one_
important thing they tweaked, that will break the system.
Also using the "magic select all button" doesn't solve the problem.
Because it is the one tiddler they shouldn't have selected, that
causes trouble.
===========
Most of the tings listed above, are the reason, why I don't update
that way anymore.
I use ginsu and cook to make an update.
ginsu splits the existing TW into nicely separated directories and
files.
* plugins
* themes
* shadows
* content
Since I know, I want to keep the content stuff, I don't need to check
it.
"shadows" and "themes" directory contain a hand full of tiddlers, that
can be easily checked.
Plugins needs a bit more attention but checking 20+ files is easier
than several hundred.
If an import function is structured that way, I think handling would
be much easier.
It also gives the user some info about 3rd party plugins s/he is
using. ....
-m
chris...@gmail.com
>> * Personally, I think the self-update functionality is one of those
>> things that is too hard to test, too complex, and sets up bad
>> expectations. It should be removed and people should not do
>> self-update. ...
> Then the import function, needs to be heavily improved.
Yes, no doubt about that.
[snip]
> * plugins
> * themes
> * shadows
> * content
[snip]
> If an import function is structured that way, I think handling would
> be much easier.
That makes good sense to me.