[Pyobjc-dev] 1.0 and beyond

[Ronald O. <ous...@ci...>]

On Tuesday, Jun 17, 2003, at 00:00 Europe/Amsterdam, Jack Jansen wrote:

> First off, I suggest taking this discussion to the list. Feel free to 
> repost this if you agree.

I'll do that.

>
> On maandag, jun 16, 2003, at 22:37 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> Hi,
>>
>> I think it is time to start planning for a 1.0 release. I'd like to 
>> get this out before Python 2.3, but I have no idea when that will be 
>> released.
>
> There's something to be said both for a pre-2.3 release and for a 
> post-2.3 release. In the first case I think we should reserve the 
> version "PyObjC 1.1" for a version that is functionally equivalent to 
> 1.0, with only 2.3 compatibility and bugs fixed. Or maybe 1.0.1 is a 
> better version number, sticking to the Python version numbering 
> scheme. Hmm, no, framework-Python compatibility is a feature, I guess.

In view of our public-relations effort, doing a 1.1 after the Python 
2.3 release would be better than calling it 1.0.1. I think we should 
reserve x.y.1 releases for bugfix-only releases.

>
>> As always the main problem is documentation, we need to clean up 
>> what's there, add a more complex tutorial (maybe a document-based 
>> application) and add (better) documentation on how to manage projects 
>> (how do I add files to a PB project, how does buildapp.py work, ...).
>
> The main problem I have with the current stuff is the ramp-up time. 
> That's also what I try to spend my PyObjC time on (so if people think 
> I should spend it differently let me know). I think that with the 
> tutorial I did for 0.9 we have a reasonable introduction for people 
> coming from a Python background, the other tutorial I want to do 
> (embedding Python in an existing ObjC application) should have the 
> same function to people with an ObjC/PB background.
>
> But I don't think tutorials by themselves are enough: people have to 
> be led towards them. Which means the documentation, even what little 
> there is, has to be organized and be inviting to read. Unfortunately 
> Dinu's WikiWiki doesn't seem to be going anywhere:-( probably due to 
> more people sharing my (current) inability to use WikiWiki for useful 
> work.
>
> So, we need to tackle Documentation/index.html. I would suggest 
> sections Tutorials, Examples, Implementation notes, On-line resources. 
> I think that covers what we have at the moment. Especially the 
> examples section is important, as this is where most of our 
> documentation is currently hidden. I think there should be one page 
> (or one section in index.html) which explains *all* examples: a 
> paragraph per example explaining what the example does and (more 
> importantly) what you will learn by examining it. This needs to be 
> close together for all the examples, so that if people want to start 
> doing something new they have a starting place.
>
>> What I'd also like to do before 1.0 is adding the examples to the 
>> website, do you have any ideas on
>> how to do that? Are there good scripts for converting python source 
>> files to pretty-printed HTML
>> files? I'm thinking of creating a home page for every example, with a 
>> link to tarball containing the entire example, a description of what 
>> the example does, a screenshot and links to pretty-printed Python 
>> sources. Some way to visualize the NIB contents would also be nice.
>
> I'm not sure about this one, maybe because I can't see the point. If 
> it's for "advertising purposes", i.e. to lure people into downloading 
> the stuff, then some simple Python code should be good enough 
> (pretty-printed, indeed). The next thing I would add is a .dmg that 
> will install out-of-the-box without installing PyObjC, but this is 
> probably going to be big and hairy.
>
> I can't see why people would want to download examples when they 
> already have them in the PyObjC distribution, or were you planning to 
> not distribute them in there? I don't think I like that idea (i.e. if 
> this is what you mean please convince me:-)

There is one good reason for adding a tarball for the examples: If we 
start updating the examples on the website between releases. I thought 
that having the NIBs and source available in a downloadable format 
would be usefull, but your right: those are not very usefull without 
the rest of PyObjC.

I still think we should try to add a visualisation of the NIB 
structure, as you noticed before the NIB is a substantial part of GUI 
code and the Python code may be hard to understand without 
understanding how the NIB(s) is/are structured.

>
>> On the non-documentation side:
> My feeling is all these can wait, they're good candidates for a 1.2 
> (or 1.1) release that can try to get some more press coverage. 
> Especially in the first (say) year it would be good to do releases 
> fairly often (every 2-3 months?), as every release is a chance to get 
> coverage on the apple developer mailing list and so.

I keep forgetting about "public-relations", and keep trying to get 
everything completely right before doing releases. I do foresee a 
problem w.r.t. doing releases every 2 months: We'll run out of our 
todo-list pretty soon. We can, and probably should, expand our scopy a 
little by adding usefull (development) tools (like an embeddable 
object/class browser). That should keep us going for a while.

>> * Installation cleanup
>>   - Installer needs work (see bug on SF)
>>   - README.txt needs to be synced with reality
>>   - MANIFEST should be a MANIFEST.in
>>   - Is installing in /Library/Developer really what we want?
>
> These *do* need to be solved, indeed.

None of these are difficult, other than the last. It might be usefull 
to wait for WWDC before deciding on the last item, maybe Apple will be 
fixing the problems we're having with our current release in the next 
release of the DevTools.

>
>> Post 1.0:
>
> I have another one:
> * PyObjC runtime-only installer, or instructions on how to do this. 
> This is so developers can push this on to end-users.

I'm not sure if this is generally usefull beyond in-house development. 
If you want to distribute applications/scripts based on PyObjC you 
should really build standalone applications. That said, we should at 
least document what it the minimal subset of PyObjC that is needed for 
running applications (e.g. only the site-packages/PyObjC tree, except 
the test packages) and how you extract that from a "normal" 
installation.

Ronald