Changes between Initial Version and Version 2 of Ticket #359

Show
Ignore:
Timestamp:
02/22/09 10:02:50 (5 years ago)
Author:
rurban
Comment:

I have two questions and a proposal about our pbc policy, when we encounter a bc version mismatch and with this path a UUID mismatch.

Proposal: use the Parrot_pbc_read() options to seperate parrot from the pbc_utils.

  • parrot, pbc_to_exe and pbc_merge should fail with a "Incompatible packfile" error, when we know that it will fail: UUID and bc version mismatch. option=0
  • however, the other parrot_utils, pbc_dump, pbc_info, pbc_disassembler, parrot_debugger should only warn when reading old pbc's, esp. on a UUID mismatch. option=1

Should we be strict, as currently, or relaxed as promised as original pbc design goals? It was even designed to be more cross-version portable as I remember.

Should our deprecation policies handle this in the code? - change the uuid and bc version but keep portability for two releases.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #359

    • Property status changed from new to assigned
  • Ticket #359 – description

    initial v2  
    1 With r36890 I've enabled UUID stamping of pbc's for the t/native_pbc/ tests. tools/dev/pbc_header.pl --up works now again. 
     1With r36890 I've enabled UUID stamping of pbc's for the t/native_pbc/ tests. tools/dev/pbc_header.pl --upd works now again. 
    22 
    33In order to enable UUID's (uuid_type=1) for all PBC's I plan the following: