... managing MANY contributors....

On Sun, Nov 9, 2008 at 7:13 PM, Yarko T <[EMAIL PROTECTED]> wrote:

> for releases I wouldn't disagree...
> but this is manual, and for managing man contributors, and for applications
> depending on plugins this feels .... wrong.
>
>
> On Sun, Nov 9, 2008 at 2:02 PM, ceej <[EMAIL PROTECTED]> wrote:
>
>>
>> The best way to keep track of the version number using git is to add a
>> 'tag' for the version and update the README, just like rails does :)
>>
>> On Nov 9, 12:12 am, "Yarko T" <[EMAIL PROTECTED]> wrote:
>> > BTW - not all of this needs to be displayed - it can be used
>> > programmatically
>> >
>> > BUT!   I think a link, just as so many desktop programs use the
>> convention
>> > on "about",
>> >
>> > I would write a t2 function to display a pop-up (ajax or otherwise) with
>> > info that can be copy-pasted.
>> >
>> > From admin, I'd show the web2py stuff.
>> > From applications (in admin too?)  I'd show what you can find about the
>> > plugin / or app.
>> >
>> > Sound good?
>> >
>> > On Sun, Nov 9, 2008 at 2:07 AM, Yarko T <[EMAIL PROTECTED]> wrote:
>> > > I'm not sure about version bazaar....
>> > > I'm guessing - like those other 2 projects I mentioned - once you
>> start
>> > > merging and including a lot of collaborators in source, you might want
>> to
>> > > move to mercurial / hg.
>> >
>> > > Because of this - and even forseeing a long life for web2py, assume it
>> > > could be longer than any particular DVCS's - I would call the extended
>> > > version information just that -
>> >
>> > > VERSION_DETAILED
>> >
>> > > Assume it's multi lined (or a list of lines);
>> > > Look for keywords in it - and that way align it with some displayed
>> stuff
>> > > that is more specific than just "a bunch of lines"
>> >
>> > > For example, for me:
>> > > --------------------
>> > > D:\Workspace\Web2Py\web2py-mirror>bzr testament --strict
>> > > bazaar-ng testament short form 2.1
>> > > revision-id:
>> svn-v3-trunk0:8fb14a07-5544-0410-8dbc-e3a1454e9f17:trunk:456
>> > > sha1: 75ccbe3afcff07cb88d0c51d48d649aa6281ec0a
>> > > ----
>> > > This is keyworded except for the first line.
>> > > The most important part for me is the revision-id. (I don't know how
>> I'd
>> > > use the checksum).
>> >
>> > > Let me compare how this looks with mercurial (on my Spinx workspace):
>> > > ------------------------
>> > > D:\Profiles\cyt007\My Documents\downloads\Programming
>> > > Lang\Python\doctools\sphin
>> > > x>hg identify --id --num --branch --tags
>> > > a2c368128b17 731 default tip
>> > > ----
>> > > The bzr revision-id provides me a similar thing to the 'hg identify
>> -inbt',
>> > > that is the correlation from hg name to bzr part seems like this:
>> > > { hg: bzr,
>> > >    id: '8fb14a07-5544-0410-8dbc-e3a1454e9f17',
>> > >  num: '456',
>> > > branch: 'svn-v3-trunk0',
>> > > tags: trunk
>> > > }
>> >
>> > > .... or maybe the branch is trunk, and tags none....
>> >
>> > > Regardless, there are common parts to these, and I wouldn't name
>> things
>> > > "BZR"
>> >
>> > > There's an ID which i would expect for any DVCS (because of the
>> > > distributedness) has to be a GUID - so expect to show that;  there's a
>> short
>> > > form version number, because humans have to read this (but they are
>> not
>> > > guranteed to be unique in a distributed environ), and there's the name
>> of
>> > > the branch - who's it is - this too will always be there in some form
>> for a
>> > > DVCS.... and finally, there are tags, or labels that have been placed
>> on
>> > > this so you can identify it.
>> >
>> > > These are I think the fundamental components.
>> >
>> > > I think the only thing you need to decide is if you want to let
>> something
>> > > that parses this out of a general string be a class / DVCS specific
>> function
>> > > --- e.g. have a function to parse bazaar testaments into these 4 key
>> items,
>> > > and "other bzr specific stuff", and have the same for mercurial then -
>> if
>> > > someone branches or does a plugin on mercurial, then identify it with
>> a
>> > > mercurial parser...
>> >
>> > > Which seems to say you were close:   VERSION_BZR is not what's needed,
>> but
>> > > VERSION_VCS_NAME  probably is (to load with bzr...);
>> >
>> > > so here's what I think you need to add:
>> >
>> > > VERSION_SYS   (or VERSION_VCS_NAME, or whatever...)
>> > > VCS_ID
>> > > VCS_NUM
>> > > VCS_BRANCH
>> > > VCS_TAG
>> >
>> > > possibly also:
>> >
>> > > VERSION_DATE
>> > > VERSION_CHKSUM
>> >
>> > > How's that sound?
>> >
>> > > Thanks for considering this.
>> >
>> > > I think this is a good step - and will establish a pattern (and
>> library)
>> > > for good identification of plugins & modules & possibly applications.
>>   This
>> > > in turn will enable programs to handle dependencies, and update
>> programs to
>> > > handle things beyond core web2py in a consistent way - without being
>> > > inflexible (e.g. only working if your extension is built and stored in
>> > > bazaar).
>> >
>> > > Perhaps others who use git, svn can say if there is anything else
>> that's
>> > > needed.
>> > > I think we can add variables - if they're not needed by one VCS, they
>> can
>> > > be left empty.
>> >
>> > > Regards,
>> > > Yarko
>> >
>> > > On Sun, Nov 9, 2008 at 12:29 AM, mdipierro <[EMAIL PROTECTED]
>> >wrote:
>> >
>> > >> Currently the VERSION file is automatically generated but does not
>> > >> contain this info because it predates our use of bzr. Moreover
>> VERSION
>> > >> has to fit in one line in order to be displayed properly in admin.
>> > >> Would another file called VERSION_BZR be ok?
>> >
>> > >> How do other projects handle this?
>> >
>> > >> Massimo
>> >
>> > >> On Nov 8, 10:54 pm, "Yarko T" <[EMAIL PROTECTED]> wrote:
>> > >> > I agree, Massimo:
>> > >> > You need to define an additional variable besides the release
>> number -
>> > >>  call
>> > >> > it a revision number or build number if you want:
>> >
>> > >> > But it should include the complete identifying info;  check out the
>> >
>> > >> > % bzr testament --strict
>> >
>> > >> > command, and think about how to automatically enter this on commit,
>> and
>> > >> spit
>> > >> > this out from web2py - on command line option, on startup, from a
>> > >> running
>> > >> > web2py.
>> >
>> > >> > On Sat, Nov 8, 2008 at 4:50 PM, billf <
>> [EMAIL PROTECTED]>
>> > >> wrote:
>> >
>> > >> > > I agree that choice is good but without version numbers in the
>> > >> > > download filename it could be frustrating having to install and
>> run
>> > >> > > before you know what version you have got.
>> >
>> > >> > > On Nov 8, 10:10 pm, ceej <[EMAIL PROTECTED]> wrote:
>> > >> > > > Hi all,
>> >
>> > >> > > > I've added web2py onhttp://github.org|
>> > >> > >http://github.com/web2py/web2py/tree/master
>> >
>> > >> > > > If you don't have GIT you can just click download to download
>> as
>> > >> .zip
>> > >> > > > or .tar :)
>> >
>> > >> > > > This isn't replacing the current svn or bazzar repo's its just
>> an
>> > >> > > > extra one, you can never have too much choice in how you would
>> like
>> > >> to
>> > >> > > > download the latest web2py version :)
>> >>
>>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to