Here’s the dilemma: I need to make some massive changes to SharpMT and if I make them, I fear that I’ll end up orphaning some of the existing settings for some of the options… one of the changes would be making a new “working” directory at \Documents and Settings\
Of course, I could attempt to make a conversion utility… for the settings, I don’t much see the point. I figure that the three things that are stored there are the Drafts list, the Blog Links list, and the layout of the tabbed panels. As I see the new UI shaping up in my mind, the Advanced panel will become a full fledged tab and the Drafts panel will be removed. The only thing sticking around is the Blog Links panel and that be refreshed from the server again.
The other conversion that I’ve thought about is that of the Drafts file and that’s problematic on a couple of levels. First and foremost is that of filenames! Since the Drafts are going from a single file for all drafts to a one draft per file situation (i.e. like Word or Excel) each draft will be stored on the HD with its own filename… I plan to default this to the title of the draft itself, but like Word/Excel, you could name the files to be whatever you want… see the problem? It could be extremely ugly, very quickly, if it’s automated… [Before anyone gets on me for this new file structure, trust me when I say that it’s worth it. This will allow people to sync individual Drafts to and from the Pocket version which is a big deal for the mobile/desktop user. It also gives me a couple of freedoms in coding that I can’t over now!]
Anyway, since these products (#MT and Pocket #MT) have a following I thought I’d ask this to the community and hope it’s not a major deal… of course, because this is a free product and a part time project of mine, I reserve the right to do what I need to do, for a new version! After all, whatever whacked settings or conversions that you have to do, I’ll have to do myself for a new version. I’m just more inclined to do this new version if a) I know I’m not going to wipe out someone’s drafts in the conversion and b) there are fewer issues to troubleshoot down the road.
Comment away… I can’t please everyone but I’m curious to see what the consensus is.
Options so often seem to come back and haunt a product, mostly because they grew out of decisions that couldn’t be made at a given time.
That isn’t necessarily the case here; just a general observation. But if the short term inconvinience makes for long term stability and growth, then I think it’s alright to drop the option settings. If you could provide a small utility to spit out a readable list of options and the settings, it would help people reconstruct after upgrading quite a lot. After all, it’s an upgrade, and they’ll be into the options anyway to see if there’s anything new :)
I agree with Todd, go with the changes!
Change it as is required, don’t worry worry to much!. Maybe you could state in the readme or upon installation that this version has had some major changes, so all old settings/prefs will be lost.
Like the commercial says “Just Dew It” :p
I’m always in favor of new stuff, and it sounds like the benefits you envision will outweigh any negatives; and if some users prefer the old version they can go back to it…
Major revs are the place to break backwards compatibility. If you’re committed enough to the feature set to make the jump to 2.0, don’t let migration concerns get in the way. Worst case, people can continue to use the old version until they’re in a position to upgrade. Maybe I’m not as prolific a writer as some, but I rarely have more than two or three drafts at any given time – using 1.x long enough to wrap up any current entries is no great hardship.
Well! So far we’re all on the same page then. It’ll take a while long, because this pulling apart and restitching takes a good deal of time, but I’m already on the road to the new version. Hopefully everyone will find it just as useful a tool that 1.x has been – if not there’s always the old version! Thanks for the feedback!